Re: Issue 196, was: #110: how to determine what entity a response carries

On 18.05.2010 20:48, Henrik Nordström wrote:
> tis 2010-05-18 klockan 14:41 +0200 skrev Julian Reschke:
>
>> The message syntax allows "*" as request-target, for which no HTTP URI
>> syntax is defined
>> (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.2.6.3>
>> defines "/" and empty path to be equivalent).
>
> Didn't we reinstate the * rule regarding this? Yes we did.
>
> http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-latest.html#rfc.section.4.1.2

We did, but it is phrased as proxy-only, and to be an exception for only 
a few methods.

> and a trivial editorial correction needed there:
>
> old:
> except as noted above to replace a null path-absolute with "/".
> new:
> except as noted above to replace a null path-absolute with "/" or "*".

Good catch. (more feedback appreciated!)

>> #2 comparing effective request URIs
>>
>> We currently define comparison to be consistent with normal HTTP URI
>> comparison, except that we skip the part that makes empty paths and "/"
>> equivalent (due to #1). As far as I can tell, comparison of effective
>> request URIs is only relevant in the context of caching; and the
>> responses to "OPTIONS *" aren't cacheable anyway, so maybe we don't need
>> to special-case this.
>
> Agreed. I do not think a special case is needed.
>
> But a note about the "*" mapping maybe, to aid future protocol
> extensions.

To where, and for what kind of extensions?

> But this said, it may be worthwhile adding a rule that clients should
> not sent a null path-absolute unless they do infact mean the whole
> server ("*"), basically restricting such uses to OPTIONS. Most clients
> seem to behave like this anyway.

+1; having the mapping depend on the method name is really strange. Q: 
what does Squid do in this case?

Best regards, Julian

Received on Tuesday, 18 May 2010 19:39:16 UTC