Re: Top level .htaccess file

I can understand if this is out of scope. It feels like it should be a
choice for domains or subdomains instead of a always true or false.

This was/is the behavior of so that is one of the main things that
set expectations of my community for the last ~6 years. I don't know if
PURL was apache based in the back end or not I don't think it was. So the
method of case insensitive is different from the desire to support it.

I agree that misspellings like l for I are an issue that we have ignored
but since it's not a change from PURL we don't get flack for it.

On Tue, Mar 15, 2016 at 9:23 AM, Stian Soiland-Reyes <> wrote:

> 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" <> 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"
>> 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 <> wrote:
>>> On Tue, Mar 8, 2016 at 4:50 PM, Robert Stuart <>
>>> wrote:
>>> > I would like 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:

*Bob Stuart*
SETA Support for ODNI/CIO/IA Division
Specifications Team Co-Lead
Cell: 703-304-5864
AIM: bobStuart
Skype: cmsi-bobstuart

Received on Tuesday, 15 March 2016 13:41:58 UTC