Re: Top level .htaccess file

I'm not so sure about this..beyond binding us even closer to Apache (while
we are discussing a more flexible CSV approach)

w3id is about permanent identifiers, not a "nicer URL" service. Most URLs
today are lowercase, so why not just assume that? You would also have the
potential problem of lc vs Ic which is not covered by your rule
On 15 Mar 2016 01:13, "Robert Stuart" <robert.j.stuart@ugov.gov> wrote:

> To better help understand the need my use cases are around giving URLs to
> people in briefing decks and verbally. Much less for client systems to be
> coded and much more for humans who are bad at remembering case to use.
>
> I too am not an apache expert. My limited testing locally seemed to say
> that the .htaccess file was not hit if there was a valid path that it could
> traverse instead. That does mean it would be hit for all "bad"
> w3id.org/xxx URLs where xxx does not exist in that exact case.
>
> For humans messing up case it would be an extra .htaccess to process but I
> would hope that is a trivial load.
>
> Thanks for your consideration and for standing up this service.
>
>
> On Mon, Mar 14, 2016 at 8:22 PM, David I. Lehn <dil@lehn.org> wrote:
>
>> On Tue, Mar 8, 2016 at 4:50 PM, Robert Stuart <robert.j.stuart@ugov.gov>
>> wrote:
>> > I would like w3id.org/ic to match case insensitive. I think it could
>> be done
>> > with a top level .htaccess file that looked like:
>> >
>> > ##########################
>> > ...
>> > RewriteRule ^IC/?(.*)$  ic/$1 [NC]
>> > ##########################
>> > ...
>> > rewrite any case of IC Ic iC to ic
>> > not fire on any of the existing directories nor would it fire on ic
>> > ...
>> > would not fire on a future directory like ice
>> > would only fire when there was no directory that matched exactly
>> existing.
>> > ...
>>
>> I'm not sure I understand the reasoning for handling case differences.
>> If just one case is used won't clients just fail and get fixed if they
>> use the wrong thing?  I would guess that's how most of the semantic
>> web identifier use cases work.
>>
>> I suppose no one knows what to do here.  I don't know what the limits
>> are of what this project should support right now.  I'm sure this
>> simple rule won't be a problem today, but it just adds something that
>> would need to be handled if the server changes technology.  Apache was
>> just the quickest means to an end when we started.  Who knows what it
>> might evolve into as the service grows.  These issues can be handled
>> but it may add complexity if we implement some new non-Apache system.
>> Maybe the entire system should just be case insensitive by default?
>> Do all the redirects and let the target handle what they want.
>>
>> I don't know the internals of Apache, but I'm guessing any top level
>> rules still have to be checked for every path.  Maybe it's smart
>> enough to mostly avoid that.  Not really an issue at the current low
>> load but if everyone wants NC rules maybe it matters.
>>
>> Thoughts anyone?
>>
>> -dave
>>
>
>
>
> --
> *Bob Stuart*
> SETA Support for ODNI/CIO/IA Division
> Specifications Team Co-Lead
> Cell: 703-304-5864
> AIM: bobStuart
> Skype: cmsi-bobstuart
> TextPage: 7033045864@txt.att.net
> Robert.J.Stuart@ugov.gov
>