- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 22 Apr 2010 16:55:02 +0200
- To: HTTP Working Group <ietf-http-wg@w3.org>
- CC: Mark Nottingham <mnot@mnot.net>, =JeffH <Jeff.Hodges@KingsMountain.com>
On 14.04.2010 17:17, Julian Reschke wrote: > On 13.04.2010 16:41, Julian Reschke wrote: >> ... >> Here's proposed text for the definition of "Effective Request URI", with >> questions inlined: >> ... > > I did some more work, and started to consider how this effects Part 2 > (see > <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/196/i196.2.diff>). > > > As expected, it works well for "Identifying the Resource Associated with > a Representation" > (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-09.html#rfc.section.6.1>). > > > However, in general it's not as easy as simply replacing > "request-target" by "Effective Request URI". > > The reason for this is that with the currently proposed definition, > "Effective Request Target" is undefined for certain requests, such as > when request-target is "*" or just an authority component. > > Should we re-consider this, mapping the request > > OPTIONS * HTTP/1.1 > Host: example.org > > to the Effective Request URI > > http://example.org > > (note no trailing slash)? > ... For now I have added this to the proposed patch (which is work-in-progress), see <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/196/i196.3.diff>; the definition now reads: - snip - 4.3. Effective Request URI The term "Effective Request URI" is introduced in order to abstract away the various syntactical forms a request can take. If the request-target is an absolute-URI, then the Effective Request URI is the request-target. [[effrequri-scheme: What about the case where the given scheme name and the transport disagree? What if actual and specified port disagree? --jre]] If the request-target uses the path-absolute (plus optional query) syntax or if it is just the asterisk "*", then the Effective Request URI is constructed by concatenating o the scheme name: "http" if the request was received over an insecure TCP connection, or "https" when received over SSL/ TLS-secured TCP connection, [[effrequri-othertransports: Need to mention other future transports here? --jre]] o the character sequence "://", o the authority component, as specified in the Host header (Section 9.4) and determined by the rules in Section 4.2, [[effrequri-nohost: How do we deal with undefined hosts? --jre]] and o the request-target obtained from the Request-Line, unless the request-target is just the asterisk "*". Otherwise, when request-target uses the authority form, the Effective Request URI is undefined. Example 1: the Effective Request URI for the message GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.example.org:8080 (received over an insecure TCP connection) is "http", plus "://", plus the authority component "www.example.org:8080", plus the request-target "/pub/WWW/TheProject.html", thus "http://www.example.org:8080/pub/WWW/TheProject.html". Example 2: the Effective Request URI for the message GET * HTTP/1.1 Host: www.example.org (received over an SSL/TLS secured TCP connection) is "https", plus "://", plus the authority component "www.example.org", thus "https://www.example.org". [[eru-options: Need to point out that we are not defining an URI for OPTIONS * here. --jre]] [[effrequri-compare: Need to declare comparison? Can we re-use the comparison defined in Section 2.6.3? --jre]] - snip - Best regards, Julian
Received on Thursday, 22 April 2010 14:55:44 UTC