W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2010

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

From: Henrik Nordström <henrik@henriknordstrom.net>
Date: Tue, 18 May 2010 20:48:22 +0200
To: Julian Reschke <julian.reschke@gmx.de>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1274208502.20274.12.camel@localhost.localdomain>
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

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 "*".

> #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.

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.

Regards
Henrik
Received on Tuesday, 18 May 2010 18:48:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:18 GMT