Mailing List Archive: DAViCal: Dev

apache rewrite foo

Index | Next | Previous | View Threaded

oliver+list at schinagl

Jun 19, 2012, 3:09 PM

Post #1 of 8 (1013 views)
Permalink

apache rewrite foo

Hi list,

I was reading the davical wiki, http://wiki.davical.org/w/Apache_Config
and failed to properly configure my web-server to fulfill all my wishes.
Hopefully someone on this list can help.

What I want is two things working simultaneously, from one domain. If
not possible, I suppose I can use one option per domain.

For one, I have davical installed in a subdir, to keep things neat and
tidy. caldav.domain.tld points to /var/www/caldav.domain.tld/htdocs
davical is installed into /var/www/caldav.domain.tld/htdocs/davical
In the davical root there is a simple index.php that does a redirect to
/davical.

What I want is the traditional way to work, for backwards compatibility
and clients that are weird to configure (iOS 5 for exaple). So
https://caldav.domain.tld/davical/caldav.php/user should always work as
that is the intended way.

For clients that properly handle things, to make things easy when
configuring clients and to have things look 'neat'
https://caldav.domain.tld/user (obviously in both cases optionally
followed by /resource) should work as well.

Thirdly, I suppose optionally would be nice to have, is
https://caldav.domain.tld/davical/user

The wiki does list a configuration that would satisfy the first and
third option I believe, but because of my attempt to work in option 2 as
well, things break.

I have changed /cal to /davical where only 'cal' was found.
I have adapted
RewriteCond /usr/share/davical/htdocs/$1 !-d
to include htdocs/davical/$1 to point to the subdir
I have modified
RewriteRule ^/cal/(.*)$ /cal/caldav.php/$1 [NC,PT]
to
RewriteRule ^/(.*)$ /davical/caldav.php/$1 [NC,PT]

And this is where I think it goes bad, with it trying to rewrite
everything after a slash? (my rewriting skills are near-nonexistant)

Not only that, I assumed that the first RewriteCond would not do any
rewriting after /davical/ thus that all original queries remained fully
functional, e.g. the admin.php webinterface (There I get the following
XML error: This XML file does not appear to have any style information
associated with it. The document tree is shown below.)

And the second RewriteCond would specifically target these files (when
using https://caldav.domain.tld/admin.php?)

Finally, I find these in my ssl logs: davical: LOG: response:-->
<href>/davical/caldav.php/davical/caldav.php/oliver/</href>

Any pointers/updates to the wiki would be appreciated!

Oliver
_______________________________________________
DAViCal-dev mailing list
DAViCal-dev [at] lists
http://lists.davical.org/listinfo/davical-dev

matthias.althaus at iserv

Jun 21, 2012, 1:17 AM

Post #2 of 8 (984 views)
Permalink

Re: apache rewrite foo [In reply to]

Hey,

>What I want is the traditional way to work, for backwards compatibility
>and clients that are weird to configure (iOS 5 for exaple). So
>https://caldav.domain.tld/davical/caldav.php/user should always work as
>that is the intended way.

What's your issue with iOS 5? We're running the usual setup and the iPhone is just happy if you point it to caldav.domain.tld (which rewrites everything to caldav.php).

Other calendar tools use caldav.domain.tld/user.name/calendar.

We're trying to make the URLs as short as possible. So I don't see a need for domain/davical/user at all.

If you're having trouble with mod_rewrite I recommend to activate its logging. With a log level around 5 you'll get so much details on what he's doing that you easily should be able to sort out your problems.

Cheers
Matthias
_______________________________________________
DAViCal-dev mailing list
DAViCal-dev [at] lists
http://lists.davical.org/listinfo/davical-dev

oliver at schinagl

Jun 21, 2012, 1:13 PM

Post #3 of 8 (967 views)
Permalink

Re: apache rewrite foo [In reply to]

I currently have setup 2 domains accessing the same server, one with
re-write rules, one without.

I currently use these rewrite rules which redirects everything except
for 'known' files. It's really dirty, but works :)

RewriteCond %{REQUEST_URI} !\.(php|css|js|png|gif|jpg)
RewriteRule ^(.*)$ /davical/caldav.php/$1 [NC,L]

That however didn't work with iOS for some reason. (I since however set
it up iOS using 'iphone configuration utility' where you can actually
specify the exact URL, and I belive that works either/or).

Anyway, the wiki lists 3 methods of rewriting, but not the one I would
like to see on the wiki (as I know very little URL rewriting) would be that:

a) https://domain.tld/davical/caldav.php/user/calendar
b) https://domain.tld/user/calendar
c) https://domain.tld/caldav.php/user/calendar

all three work simultaneously, while still being able to access
admin.php for config work.

method a) would be the 'no rewriting at all' as that's where davical is
installed. It is actually the least important one, but currently the
only one that works for iOS (when setting it up using a specific URL
using iuc). Also having the 'vanilla' url working is nice when using
admin.php

method b) gives the cleanest user experience. I hadn't gotten iOS
working using my rewriting rules using /user with a domain of
caldav.domain.tld in iOS (even combining the both in the iOS 'url' field
didn't work as expected).

method c) for really broken clients I suppose though it could obsolete
method a)

On 06/21/12 10:17, Matthias Althaus wrote:
> Hey,
>
>> What I want is the traditional way to work, for backwards compatibility
>> and clients that are weird to configure (iOS 5 for exaple). So
>> https://caldav.domain.tld/davical/caldav.php/user should always work as
>> that is the intended way.
>
> What's your issue with iOS 5? We're running the usual setup and the iPhone is just happy if you point it to caldav.domain.tld (which rewrites everything to caldav.php).
>
> Other calendar tools use caldav.domain.tld/user.name/calendar.
>
> We're trying to make the URLs as short as possible. So I don't see a need for domain/davical/user at all.
>
> If you're having trouble with mod_rewrite I recommend to activate its logging. With a log level around 5 you'll get so much details on what he's doing that you easily should be able to sort out your problems.
>
> Cheers
> Matthias
> _______________________________________________
> DAViCal-dev mailing list
> DAViCal-dev [at] lists
> http://lists.davical.org/listinfo/davical-dev

_______________________________________________
DAViCal-dev mailing list
DAViCal-dev [at] lists
http://lists.davical.org/listinfo/davical-dev

andrew at morphoss

Jun 22, 2012, 4:48 AM

Post #4 of 8 (968 views)
Permalink

Re: apache rewrite foo [In reply to]

On Thu, 2012-06-21 at 22:13 +0200, Oliver Schinagl wrote:
> I currently have setup 2 domains accessing the same server, one with
> re-write rules, one without.
>
> I currently use these rewrite rules which redirects everything except
> for 'known' files. It's really dirty, but works :)
>
> RewriteCond %{REQUEST_URI} !\.(php|css|js|png|gif|jpg)
> RewriteRule ^(.*)$ /davical/caldav.php/$1 [NC,L]
>
>
> That however didn't work with iOS for some reason. (I since however set
> it up iOS using 'iphone configuration utility' where you can actually
> specify the exact URL, and I belive that works either/or).
>
> Anyway, the wiki lists 3 methods of rewriting, but not the one I would
> like to see on the wiki (as I know very little URL rewriting) would be that:
>
> a) https://domain.tld/davical/caldav.php/user/calendar
> b) https://domain.tld/user/calendar
> c) https://domain.tld/caldav.php/user/calendar
>
> all three work simultaneously, while still being able to access
> admin.php for config work.
>
> method a) would be the 'no rewriting at all' as that's where davical is
> installed. It is actually the least important one, but currently the
> only one that works for iOS (when setting it up using a specific URL
> using iuc). Also having the 'vanilla' url working is nice when using
> admin.php
>
> method b) gives the cleanest user experience. I hadn't gotten iOS
> working using my rewriting rules using /user with a domain of
> caldav.domain.tld in iOS (even combining the both in the iOS 'url' field
> didn't work as expected).
>
> method c) for really broken clients I suppose though it could obsolete
> method a)

Apple products look for the /.well-known/caldav and /.well-known/carddav
URLs, so if you arrange to redirect those two URLs to /davical/ then it
should work fine in mode (a) when you just enter the domain name into
the client application. You can also use Apache's "Alias" command to
alias those URLs directly to DAViCal's caldav.php - it'll figure out
what's going on and Do The Right Thing (tm).

Alternatively, make DAViCal listen on port 8443 SSL instead of 443, and
give it that virtualhost the whole path space. All CalDAV clients that
try and do any sort of discovery will also look there for a CalDAV
server too.

Then you'd end up with URLs like:
https://domain.tld:8443/caldav.php/user/calendar/

Cheers,
Andrew.

> On 06/21/12 10:17, Matthias Althaus wrote:
> > Hey,
> >
> >> What I want is the traditional way to work, for backwards compatibility
> >> and clients that are weird to configure (iOS 5 for exaple). So
> >> https://caldav.domain.tld/davical/caldav.php/user should always work as
> >> that is the intended way.
> >
> > What's your issue with iOS 5? We're running the usual setup and the iPhone is just happy if you point it to caldav.domain.tld (which rewrites everything to caldav.php).
> >
> > Other calendar tools use caldav.domain.tld/user.name/calendar.
> >
> > We're trying to make the URLs as short as possible. So I don't see a need for domain/davical/user at all.
> >
> > If you're having trouble with mod_rewrite I recommend to activate its logging. With a log level around 5 you'll get so much details on what he's doing that you easily should be able to sort out your problems.
> >
> > Cheers
> > Matthias
> > _______________________________________________
> > DAViCal-dev mailing list
> > DAViCal-dev [at] lists
> > http://lists.davical.org/listinfo/davical-dev
>
> _______________________________________________
> DAViCal-dev mailing list
> DAViCal-dev [at] lists
> http://lists.davical.org/listinfo/davical-dev
>

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
So you're back... about time...
------------------------------------------------------------------------

Attachments:

signature.asc (0.82 KB)

oliver+list at schinagl

Jun 29, 2012, 5:21 AM

Post #5 of 8 (944 views)
Permalink

Re: apache rewrite foo [In reply to]

On 06/25/12 01:55, Andrew McMillan wrote:
> On Sat, 2012-06-23 at 22:57 +0200, Oliver Schinagl wrote:
>> On 06/22/12 13:48, Andrew McMillan wrote:
>>> On Thu, 2012-06-21 at 22:13 +0200, Oliver Schinagl wrote:
>>>> I currently have setup 2 domains accessing the same server, one with
>>>> re-write rules, one without.
>>>>
>>>> I currently use these rewrite rules which redirects everything except
>>>> for 'known' files. It's really dirty, but works :)
>>>>
>>>> RewriteCond %{REQUEST_URI} !\.(php|css|js|png|gif|jpg)
>>>> RewriteRule ^(.*)$ /davical/caldav.php/$1 [NC,L]
>>>>
>>>>
>>>> That however didn't work with iOS for some reason. (I since however set
>>>> it up iOS using 'iphone configuration utility' where you can actually
>>>> specify the exact URL, and I belive that works either/or).
>>>>
>>>> Anyway, the wiki lists 3 methods of rewriting, but not the one I would
>>>> like to see on the wiki (as I know very little URL rewriting) would be that:
>>>>
>>>> a) https://domain.tld/davical/caldav.php/user/calendar
>>>> b) https://domain.tld/user/calendar
>>>> c) https://domain.tld/caldav.php/user/calendar
>>>>
>>>> all three work simultaneously, while still being able to access
>>>> admin.php for config work.
>>>>
>>>> method a) would be the 'no rewriting at all' as that's where davical is
>>>> installed. It is actually the least important one, but currently the
>>>> only one that works for iOS (when setting it up using a specific URL
>>>> using iuc). Also having the 'vanilla' url working is nice when using
>>>> admin.php
>>>>
>>>> method b) gives the cleanest user experience. I hadn't gotten iOS
>>>> working using my rewriting rules using /user with a domain of
>>>> caldav.domain.tld in iOS (even combining the both in the iOS 'url' field
>>>> didn't work as expected).
>>>>
>>>> method c) for really broken clients I suppose though it could obsolete
>>>> method a)
>>>
>>> Apple products look for the /.well-known/caldav and /.well-known/carddav
>>> URLs, so if you arrange to redirect those two URLs to /davical/ then it
>>> should work fine in mode (a) when you just enter the domain name into
>>> the client application. You can also use Apache's "Alias" command to
>>> alias those URLs directly to DAViCal's caldav.php - it'll figure out
>>> what's going on and Do The Right Thing (tm).
>> I would have thought so, but due to my previous rewrite rules in place,
>> it didn't work any more :(
>
> What I am saying is get rid of *all* rewrite rules and only have alias
> and/or rewrite rules for those two URLs.
Ok, clear rewrite rules (I did that and copied those from the wiki). I
will experiment and test more, but no longer have an iOS device :p

>
>
>>> Alternatively, make DAViCal listen on port 8443 SSL instead of 443, and
>>> give it that virtualhost the whole path space. All CalDAV clients that
>>> try and do any sort of discovery will also look there for a CalDAV
>>> server too.
>> I coincidentally had my server configured on 8443 next to being on 443
>> (I needed it to have both ssh and ssl on 443, sslh)
>>
>> It would find everything just fine actually; but it just showed me one
>> (or none?) empty calendar)
>
> If you have it on both I expect you are using the same VirtualHost
> stanza for both, and so you have the same non-root URL problem for
> both...
>
> If you get rid of the references to :443 and install it on 8443 in the
> root path then all your problems should disappear. No need for any
> rewriting etc, if https://domain.tld:8443/ is the base.
Well I have it running on both ports and cal.domain.tld has no rewrite
rules, so that works perfectly :)
>
> Cheers,
> Andrew.
>>
>>>
>>> Then you'd end up with URLs like:
>>> https://domain.tld:8443/caldav.php/user/calendar/
>>>
>> yep, that's what I actually have for the subdomain 'cal' (with either
>> 8443 or 443 working). caldav is the one I have my rewrite in place.
>>
>> Maybe I'm just over thinking things, or haven't tried things properly :)
>>> Cheers,
>>> Andrew.
>>>
>>>> On 06/21/12 10:17, Matthias Althaus wrote:
>>>>> Hey,
>>>>>
>>>>>> What I want is the traditional way to work, for backwards compatibility
>>>>>> and clients that are weird to configure (iOS 5 for exaple). So
>>>>>> https://caldav.domain.tld/davical/caldav.php/user should always work as
>>>>>> that is the intended way.
>>>>>
>>>>> What's your issue with iOS 5? We're running the usual setup and the iPhone is just happy if you point it to caldav.domain.tld (which rewrites everything to caldav.php).
>>>>>
>>>>> Other calendar tools use caldav.domain.tld/user.name/calendar.
>>>>>
>>>>> We're trying to make the URLs as short as possible. So I don't see a need for domain/davical/user at all.
>>>>>
>>>>> If you're having trouble with mod_rewrite I recommend to activate its logging. With a log level around 5 you'll get so much details on what he's doing that you easily should be able to sort out your problems.
>>>>>
>>>>> Cheers
>>>>> Matthias
>>>>> _______________________________________________
>>>>> DAViCal-dev mailing list
>>>>> DAViCal-dev [at] lists
>>>>> http://lists.davical.org/listinfo/davical-dev
>>>>
>>>> _______________________________________________
>>>> DAViCal-dev mailing list
>>>> DAViCal-dev [at] lists
>>>> http://lists.davical.org/listinfo/davical-dev
>>>>
>>>
>>
>

_______________________________________________
DAViCal-dev mailing list
DAViCal-dev [at] lists
http://lists.davical.org/listinfo/davical-dev

oliver+list at schinagl

Jul 27, 2012, 5:21 AM

Post #6 of 8 (884 views)
Permalink

Re: apache rewrite foo [In reply to]

I have setup a new server and have setup the rewrite rules per the wiki.

I have set up the recipe using a virtual host, making the caldav.php bit
no longer required and bypassing the subdir wherre davical is installed.

E.g. the plan is still, rewrite
https://caldav.domain.tld/davical/caldav.php/user/calendar to
https://caldav.domain.tld/user/calendar

I used: (copied down from writing, not copy paste)
RewriteCond %{REQUEST_URI} !\.(php|css|js|png|gif|jpg)

Rewrite %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d (and -f on duplicate line)
RewriteRule ^(.*)$ /davical/caldav.php/$1 [NC,L]

This works fine, for lightening. However iOS pukes and ignores it.

Original message below:

On 29-06-12 14:21, Oliver Schinagl wrote:
> On 06/25/12 01:55, Andrew McMillan wrote:
>> On Sat, 2012-06-23 at 22:57 +0200, Oliver Schinagl wrote:
>>> On 06/22/12 13:48, Andrew McMillan wrote:
>>>> On Thu, 2012-06-21 at 22:13 +0200, Oliver Schinagl wrote:
>>>>> I currently have setup 2 domains accessing the same server, one with
>>>>> re-write rules, one without.
>>>>>
>>>>> I currently use these rewrite rules which redirects everything except
>>>>> for 'known' files. It's really dirty, but works :)
>>>>>
>>>>> RewriteCond %{REQUEST_URI} !\.(php|css|js|png|gif|jpg)
>>>>> RewriteRule ^(.*)$ /davical/caldav.php/$1 [NC,L]
>>>>>
>>>>>
>>>>> That however didn't work with iOS for some reason. (I since
>>>>> however set
>>>>> it up iOS using 'iphone configuration utility' where you can actually
>>>>> specify the exact URL, and I belive that works either/or).
>>>>>
>>>>> Anyway, the wiki lists 3 methods of rewriting, but not the one I
>>>>> would
>>>>> like to see on the wiki (as I know very little URL rewriting)
>>>>> would be that:
>>>>>
>>>>> a) https://domain.tld/davical/caldav.php/user/calendar
>>>>> b) https://domain.tld/user/calendar
>>>>> c) https://domain.tld/caldav.php/user/calendar
>>>>>
>>>>> all three work simultaneously, while still being able to access
>>>>> admin.php for config work.
>>>>>
>>>>> method a) would be the 'no rewriting at all' as that's where
>>>>> davical is
>>>>> installed. It is actually the least important one, but currently the
>>>>> only one that works for iOS (when setting it up using a specific URL
>>>>> using iuc). Also having the 'vanilla' url working is nice when using
>>>>> admin.php
>>>>>
>>>>> method b) gives the cleanest user experience. I hadn't gotten iOS
>>>>> working using my rewriting rules using /user with a domain of
>>>>> caldav.domain.tld in iOS (even combining the both in the iOS 'url'
>>>>> field
>>>>> didn't work as expected).
>>>>>
>>>>> method c) for really broken clients I suppose though it could
>>>>> obsolete
>>>>> method a)
>>>>
>>>> Apple products look for the /.well-known/caldav and
>>>> /.well-known/carddav
>>>> URLs, so if you arrange to redirect those two URLs to /davical/
>>>> then it
>>>> should work fine in mode (a) when you just enter the domain name into
>>>> the client application. You can also use Apache's "Alias" command to
>>>> alias those URLs directly to DAViCal's caldav.php - it'll figure out
>>>> what's going on and Do The Right Thing (tm).
>>> I would have thought so, but due to my previous rewrite rules in place,
>>> it didn't work any more :(
>>
>> What I am saying is get rid of *all* rewrite rules and only have alias
>> and/or rewrite rules for those two URLs.
> Ok, clear rewrite rules (I did that and copied those from the wiki). I
> will experiment and test more, but no longer have an iOS device :p
>
>>
>>
>>>> Alternatively, make DAViCal listen on port 8443 SSL instead of 443,
>>>> and
>>>> give it that virtualhost the whole path space. All CalDAV clients
>>>> that
>>>> try and do any sort of discovery will also look there for a CalDAV
>>>> server too.
>>> I coincidentally had my server configured on 8443 next to being on 443
>>> (I needed it to have both ssh and ssl on 443, sslh)
>>>
>>> It would find everything just fine actually; but it just showed me one
>>> (or none?) empty calendar)
>>
>> If you have it on both I expect you are using the same VirtualHost
>> stanza for both, and so you have the same non-root URL problem for
>> both...
>>
>> If you get rid of the references to :443 and install it on 8443 in the
>> root path then all your problems should disappear. No need for any
>> rewriting etc, if https://domain.tld:8443/ is the base.
> Well I have it running on both ports and cal.domain.tld has no rewrite
> rules, so that works perfectly :)
>>
>> Cheers,
>> Andrew.
>>>
>>>>
>>>> Then you'd end up with URLs like:
>>>> https://domain.tld:8443/caldav.php/user/calendar/
>>>>
>>> yep, that's what I actually have for the subdomain 'cal' (with either
>>> 8443 or 443 working). caldav is the one I have my rewrite in place.
>>>
>>> Maybe I'm just over thinking things, or haven't tried things
>>> properly :)
>>>> Cheers,
>>>> Andrew.
>>>>
>>>>> On 06/21/12 10:17, Matthias Althaus wrote:
>>>>>> Hey,
>>>>>>
>>>>>>> What I want is the traditional way to work, for backwards
>>>>>>> compatibility
>>>>>>> and clients that are weird to configure (iOS 5 for exaple). So
>>>>>>> https://caldav.domain.tld/davical/caldav.php/user should always
>>>>>>> work as
>>>>>>> that is the intended way.
>>>>>>
>>>>>> What's your issue with iOS 5? We're running the usual setup and
>>>>>> the iPhone is just happy if you point it to caldav.domain.tld
>>>>>> (which rewrites everything to caldav.php).
>>>>>>
>>>>>> Other calendar tools use caldav.domain.tld/user.name/calendar.
>>>>>>
>>>>>> We're trying to make the URLs as short as possible. So I don't
>>>>>> see a need for domain/davical/user at all.
>>>>>>
>>>>>> If you're having trouble with mod_rewrite I recommend to activate
>>>>>> its logging. With a log level around 5 you'll get so much details
>>>>>> on what he's doing that you easily should be able to sort out
>>>>>> your problems.
>>>>>>
>>>>>> Cheers
>>>>>> Matthias
>>>>>> _______________________________________________
>>>>>> DAViCal-dev mailing list
>>>>>> DAViCal-dev [at] lists
>>>>>> http://lists.davical.org/listinfo/davical-dev
>>>>>
>>>>> _______________________________________________
>>>>> DAViCal-dev mailing list
>>>>> DAViCal-dev [at] lists
>>>>> http://lists.davical.org/listinfo/davical-dev
>>>>>
>>>>
>>>
>>
>
> _______________________________________________
> DAViCal-dev mailing list
> DAViCal-dev [at] lists
> http://lists.davical.org/listinfo/davical-dev

_______________________________________________
DAViCal-dev mailing list
DAViCal-dev [at] lists
http://lists.davical.org/listinfo/davical-dev

andrew at morphoss

Jul 29, 2012, 5:35 AM

Post #7 of 8 (889 views)
Permalink

Re: apache rewrite foo [In reply to]

On Fri, 2012-07-27 at 14:21 +0200, Oliver Schinagl wrote:
> I have setup a new server and have setup the rewrite rules per the wiki.
>
> I have set up the recipe using a virtual host, making the caldav.php bit
> no longer required and bypassing the subdir where davical is installed.
>
> E.g. the plan is still, rewrite
> https://caldav.domain.tld/davical/caldav.php/user/calendar to
> https://caldav.domain.tld/user/calendar
>
> I used: (copied down from writing, not copy paste)
> RewriteCond %{REQUEST_URI} !\.(php|css|js|png|gif|jpg)
>
> Rewrite %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d (and -f on duplicate line)
> RewriteRule ^(.*)$ /davical/caldav.php/$1 [NC,L]
>
>
> This works fine, for lightning. However iOS pukes and ignores it.

In general I think using the rewrite rules is overrated. The client
should not need them. In particular the rewriting you want to do above
from .../davical/caldav.php/username/... to .../username/... just seems
wrong. If you want DAViCal running in the root of your virtualhost, why
not put it there? The URLs don't really need rewriting, since you only
have to type (cut and paste?) them very infrequently in any case.

Cheers,
Andrew.

> Original message below:
>
> On 29-06-12 14:21, Oliver Schinagl wrote:
> > On 06/25/12 01:55, Andrew McMillan wrote:
> >> On Sat, 2012-06-23 at 22:57 +0200, Oliver Schinagl wrote:
> >>> On 06/22/12 13:48, Andrew McMillan wrote:
> >>>> On Thu, 2012-06-21 at 22:13 +0200, Oliver Schinagl wrote:
> >>>>> I currently have setup 2 domains accessing the same server, one with
> >>>>> re-write rules, one without.
> >>>>>
> >>>>> I currently use these rewrite rules which redirects everything except
> >>>>> for 'known' files. It's really dirty, but works :)
> >>>>>
> >>>>> RewriteCond %{REQUEST_URI} !\.(php|css|js|png|gif|jpg)
> >>>>> RewriteRule ^(.*)$ /davical/caldav.php/$1 [NC,L]
> >>>>>
> >>>>>
> >>>>> That however didn't work with iOS for some reason. (I since
> >>>>> however set
> >>>>> it up iOS using 'iphone configuration utility' where you can actually
> >>>>> specify the exact URL, and I belive that works either/or).
> >>>>>
> >>>>> Anyway, the wiki lists 3 methods of rewriting, but not the one I
> >>>>> would
> >>>>> like to see on the wiki (as I know very little URL rewriting)
> >>>>> would be that:
> >>>>>
> >>>>> a) https://domain.tld/davical/caldav.php/user/calendar
> >>>>> b) https://domain.tld/user/calendar
> >>>>> c) https://domain.tld/caldav.php/user/calendar
> >>>>>
> >>>>> all three work simultaneously, while still being able to access
> >>>>> admin.php for config work.
> >>>>>
> >>>>> method a) would be the 'no rewriting at all' as that's where
> >>>>> davical is
> >>>>> installed. It is actually the least important one, but currently the
> >>>>> only one that works for iOS (when setting it up using a specific URL
> >>>>> using iuc). Also having the 'vanilla' url working is nice when using
> >>>>> admin.php
> >>>>>
> >>>>> method b) gives the cleanest user experience. I hadn't gotten iOS
> >>>>> working using my rewriting rules using /user with a domain of
> >>>>> caldav.domain.tld in iOS (even combining the both in the iOS 'url'
> >>>>> field
> >>>>> didn't work as expected).
> >>>>>
> >>>>> method c) for really broken clients I suppose though it could
> >>>>> obsolete
> >>>>> method a)
> >>>>
> >>>> Apple products look for the /.well-known/caldav and
> >>>> /.well-known/carddav
> >>>> URLs, so if you arrange to redirect those two URLs to /davical/
> >>>> then it
> >>>> should work fine in mode (a) when you just enter the domain name into
> >>>> the client application. You can also use Apache's "Alias" command to
> >>>> alias those URLs directly to DAViCal's caldav.php - it'll figure out
> >>>> what's going on and Do The Right Thing (tm).
> >>> I would have thought so, but due to my previous rewrite rules in place,
> >>> it didn't work any more :(
> >>
> >> What I am saying is get rid of *all* rewrite rules and only have alias
> >> and/or rewrite rules for those two URLs.
> > Ok, clear rewrite rules (I did that and copied those from the wiki). I
> > will experiment and test more, but no longer have an iOS device :p
> >
> >>
> >>
> >>>> Alternatively, make DAViCal listen on port 8443 SSL instead of 443,
> >>>> and
> >>>> give it that virtualhost the whole path space. All CalDAV clients
> >>>> that
> >>>> try and do any sort of discovery will also look there for a CalDAV
> >>>> server too.
> >>> I coincidentally had my server configured on 8443 next to being on 443
> >>> (I needed it to have both ssh and ssl on 443, sslh)
> >>>
> >>> It would find everything just fine actually; but it just showed me one
> >>> (or none?) empty calendar)
> >>
> >> If you have it on both I expect you are using the same VirtualHost
> >> stanza for both, and so you have the same non-root URL problem for
> >> both...
> >>
> >> If you get rid of the references to :443 and install it on 8443 in the
> >> root path then all your problems should disappear. No need for any
> >> rewriting etc, if https://domain.tld:8443/ is the base.
> > Well I have it running on both ports and cal.domain.tld has no rewrite
> > rules, so that works perfectly :)
> >>
> >> Cheers,
> >> Andrew.
> >>>
> >>>>
> >>>> Then you'd end up with URLs like:
> >>>> https://domain.tld:8443/caldav.php/user/calendar/
> >>>>
> >>> yep, that's what I actually have for the subdomain 'cal' (with either
> >>> 8443 or 443 working). caldav is the one I have my rewrite in place.
> >>>
> >>> Maybe I'm just over thinking things, or haven't tried things
> >>> properly :)
> >>>> Cheers,
> >>>> Andrew.
> >>>>
> >>>>> On 06/21/12 10:17, Matthias Althaus wrote:
> >>>>>> Hey,
> >>>>>>
> >>>>>>> What I want is the traditional way to work, for backwards
> >>>>>>> compatibility
> >>>>>>> and clients that are weird to configure (iOS 5 for exaple). So
> >>>>>>> https://caldav.domain.tld/davical/caldav.php/user should always
> >>>>>>> work as
> >>>>>>> that is the intended way.
> >>>>>>
> >>>>>> What's your issue with iOS 5? We're running the usual setup and
> >>>>>> the iPhone is just happy if you point it to caldav.domain.tld
> >>>>>> (which rewrites everything to caldav.php).
> >>>>>>
> >>>>>> Other calendar tools use caldav.domain.tld/user.name/calendar.
> >>>>>>
> >>>>>> We're trying to make the URLs as short as possible. So I don't
> >>>>>> see a need for domain/davical/user at all.
> >>>>>>
> >>>>>> If you're having trouble with mod_rewrite I recommend to activate
> >>>>>> its logging. With a log level around 5 you'll get so much details
> >>>>>> on what he's doing that you easily should be able to sort out
> >>>>>> your problems.
> >>>>>>
> >>>>>> Cheers
> >>>>>> Matthias
> >>>>>> _______________________________________________
> >>>>>> DAViCal-dev mailing list
> >>>>>> DAViCal-dev [at] lists
> >>>>>> http://lists.davical.org/listinfo/davical-dev
> >>>>>
> >>>>> _______________________________________________
> >>>>> DAViCal-dev mailing list
> >>>>> DAViCal-dev [at] lists
> >>>>> http://lists.davical.org/listinfo/davical-dev
> >>>>>
> >>>>
> >>>
> >>
> >
> > _______________________________________________
> > DAViCal-dev mailing list
> > DAViCal-dev [at] lists
> > http://lists.davical.org/listinfo/davical-dev
>
> _______________________________________________
> DAViCal-dev mailing list
> DAViCal-dev [at] lists
> http://lists.davical.org/listinfo/davical-dev
>

--
------------------------------------------------------------------------
andrew (AT) morphoss (DOT) com +64(272)DEBIAN
Limited time offer, call now to ensure prompt delivery.
------------------------------------------------------------------------

Attachments:

signature.asc (0.82 KB)

oliver+list at schinagl

Jul 30, 2012, 12:18 PM

Post #8 of 8 (881 views)
Permalink

Re: apache rewrite foo [In reply to]

On 29-07-12 14:35, Andrew McMillan wrote:
> On Fri, 2012-07-27 at 14:21 +0200, Oliver Schinagl wrote:
>> I have setup a new server and have setup the rewrite rules per the wiki.
>>
>> I have set up the recipe using a virtual host, making the caldav.php bit
>> no longer required and bypassing the subdir where davical is installed.
>>
>> E.g. the plan is still, rewrite
>> https://caldav.domain.tld/davical/caldav.php/user/calendar to
>> https://caldav.domain.tld/user/calendar
>>
>> I used: (copied down from writing, not copy paste)
>> RewriteCond %{REQUEST_URI} !\.(php|css|js|png|gif|jpg)
>>
>> Rewrite %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d (and -f on duplicate line)
>> RewriteRule ^(.*)$ /davical/caldav.php/$1 [NC,L]
>>
>>
>> This works fine, for lightning. However iOS pukes and ignores it.
> In general I think using the rewrite rules is overrated. The client
> should not need them. In particular the rewriting you want to do above
> from .../davical/caldav.php/username/... to .../username/... just seems
> wrong. If you want DAViCal running in the root of your virtualhost, why
> not put it there? The URLs don't really need rewriting, since you only
> have to type (cut and paste?) them very infrequently in any case.
The URL's are way to long to type on a touchscreen and quite error
prone. It also looks long and confusing, especially for non-technical
users. They also look 'bad' when they are long to a user.

I've come accustomed to not have any packages in the virtualhost's root
Very Occasionally I have more then one package installed into a virtual
host. Also it makes versioning easier, having two versions in one
virtual host ;)

Especially the renaming from username to caldav.php cleans it up a lot.

I'm quite sure technically it's quite possible :) I just have to admit
defeat that my technical knowledge in this specific area falls extremely
short.

>
> Cheers,
> Andrew.
>
>> Original message below:
>>
>> On 29-06-12 14:21, Oliver Schinagl wrote:
>>> On 06/25/12 01:55, Andrew McMillan wrote:
>>>> On Sat, 2012-06-23 at 22:57 +0200, Oliver Schinagl wrote:
>>>>> On 06/22/12 13:48, Andrew McMillan wrote:
>>>>>> On Thu, 2012-06-21 at 22:13 +0200, Oliver Schinagl wrote:
>>>>>>> I currently have setup 2 domains accessing the same server, one with
>>>>>>> re-write rules, one without.
>>>>>>>
>>>>>>> I currently use these rewrite rules which redirects everything except
>>>>>>> for 'known' files. It's really dirty, but works :)
>>>>>>>
>>>>>>> RewriteCond %{REQUEST_URI} !\.(php|css|js|png|gif|jpg)
>>>>>>> RewriteRule ^(.*)$ /davical/caldav.php/$1 [NC,L]
>>>>>>>
>>>>>>>
>>>>>>> That however didn't work with iOS for some reason. (I since
>>>>>>> however set
>>>>>>> it up iOS using 'iphone configuration utility' where you can actually
>>>>>>> specify the exact URL, and I belive that works either/or).
>>>>>>>
>>>>>>> Anyway, the wiki lists 3 methods of rewriting, but not the one I
>>>>>>> would
>>>>>>> like to see on the wiki (as I know very little URL rewriting)
>>>>>>> would be that:
>>>>>>>
>>>>>>> a) https://domain.tld/davical/caldav.php/user/calendar
>>>>>>> b) https://domain.tld/user/calendar
>>>>>>> c) https://domain.tld/caldav.php/user/calendar
>>>>>>>
>>>>>>> all three work simultaneously, while still being able to access
>>>>>>> admin.php for config work.
>>>>>>>
>>>>>>> method a) would be the 'no rewriting at all' as that's where
>>>>>>> davical is
>>>>>>> installed. It is actually the least important one, but currently the
>>>>>>> only one that works for iOS (when setting it up using a specific URL
>>>>>>> using iuc). Also having the 'vanilla' url working is nice when using
>>>>>>> admin.php
>>>>>>>
>>>>>>> method b) gives the cleanest user experience. I hadn't gotten iOS
>>>>>>> working using my rewriting rules using /user with a domain of
>>>>>>> caldav.domain.tld in iOS (even combining the both in the iOS 'url'
>>>>>>> field
>>>>>>> didn't work as expected).
>>>>>>>
>>>>>>> method c) for really broken clients I suppose though it could
>>>>>>> obsolete
>>>>>>> method a)
>>>>>> Apple products look for the /.well-known/caldav and
>>>>>> /.well-known/carddav
>>>>>> URLs, so if you arrange to redirect those two URLs to /davical/
>>>>>> then it
>>>>>> should work fine in mode (a) when you just enter the domain name into
>>>>>> the client application. You can also use Apache's "Alias" command to
>>>>>> alias those URLs directly to DAViCal's caldav.php - it'll figure out
>>>>>> what's going on and Do The Right Thing (tm).
>>>>> I would have thought so, but due to my previous rewrite rules in place,
>>>>> it didn't work any more :(
>>>> What I am saying is get rid of *all* rewrite rules and only have alias
>>>> and/or rewrite rules for those two URLs.
>>> Ok, clear rewrite rules (I did that and copied those from the wiki). I
>>> will experiment and test more, but no longer have an iOS device :p
>>>
>>>>
>>>>>> Alternatively, make DAViCal listen on port 8443 SSL instead of 443,
>>>>>> and
>>>>>> give it that virtualhost the whole path space. All CalDAV clients
>>>>>> that
>>>>>> try and do any sort of discovery will also look there for a CalDAV
>>>>>> server too.
>>>>> I coincidentally had my server configured on 8443 next to being on 443
>>>>> (I needed it to have both ssh and ssl on 443, sslh)
>>>>>
>>>>> It would find everything just fine actually; but it just showed me one
>>>>> (or none?) empty calendar)
>>>> If you have it on both I expect you are using the same VirtualHost
>>>> stanza for both, and so you have the same non-root URL problem for
>>>> both...
>>>>
>>>> If you get rid of the references to :443 and install it on 8443 in the
>>>> root path then all your problems should disappear. No need for any
>>>> rewriting etc, if https://domain.tld:8443/ is the base.
>>> Well I have it running on both ports and cal.domain.tld has no rewrite
>>> rules, so that works perfectly :)
>>>> Cheers,
>>>> Andrew.
>>>>>> Then you'd end up with URLs like:
>>>>>> https://domain.tld:8443/caldav.php/user/calendar/
>>>>>>
>>>>> yep, that's what I actually have for the subdomain 'cal' (with either
>>>>> 8443 or 443 working). caldav is the one I have my rewrite in place.
>>>>>
>>>>> Maybe I'm just over thinking things, or haven't tried things
>>>>> properly :)
>>>>>> Cheers,
>>>>>> Andrew.
>>>>>>
>>>>>>> On 06/21/12 10:17, Matthias Althaus wrote:
>>>>>>>> Hey,
>>>>>>>>
>>>>>>>>> What I want is the traditional way to work, for backwards
>>>>>>>>> compatibility
>>>>>>>>> and clients that are weird to configure (iOS 5 for exaple). So
>>>>>>>>> https://caldav.domain.tld/davical/caldav.php/user should always
>>>>>>>>> work as
>>>>>>>>> that is the intended way.
>>>>>>>> What's your issue with iOS 5? We're running the usual setup and
>>>>>>>> the iPhone is just happy if you point it to caldav.domain.tld
>>>>>>>> (which rewrites everything to caldav.php).
>>>>>>>>
>>>>>>>> Other calendar tools use caldav.domain.tld/user.name/calendar.
>>>>>>>>
>>>>>>>> We're trying to make the URLs as short as possible. So I don't
>>>>>>>> see a need for domain/davical/user at all.
>>>>>>>>
>>>>>>>> If you're having trouble with mod_rewrite I recommend to activate
>>>>>>>> its logging. With a log level around 5 you'll get so much details
>>>>>>>> on what he's doing that you easily should be able to sort out
>>>>>>>> your problems.
>>>>>>>>
>>>>>>>> Cheers
>>>>>>>> Matthias
>>>>>>>> _______________________________________________
>>>>>>>> DAViCal-dev mailing list
>>>>>>>> DAViCal-dev [at] lists
>>>>>>>> http://lists.davical.org/listinfo/davical-dev
>>>>>>> _______________________________________________
>>>>>>> DAViCal-dev mailing list
>>>>>>> DAViCal-dev [at] lists
>>>>>>> http://lists.davical.org/listinfo/davical-dev
>>>>>>>
>>> _______________________________________________
>>> DAViCal-dev mailing list
>>> DAViCal-dev [at] lists
>>> http://lists.davical.org/listinfo/davical-dev
>> _______________________________________________
>> DAViCal-dev mailing list
>> DAViCal-dev [at] lists
>> http://lists.davical.org/listinfo/davical-dev
>>

_______________________________________________
DAViCal-dev mailing list
DAViCal-dev [at] lists
http://lists.davical.org/listinfo/davical-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads