re: effective request URI/target URI, issues 221 & 222, was: Issues addressed, by the -10 drafts

On 22.07.2010 23:13, Roy T. Fielding wrote:
 >
 > Is there some reason we can't just call it the target URI?


Julian Reschke <julian.reschke@gmx.de> responded..
 >
 > I think we *can* call them "target URI". The reason we picked "Effective
 > Request URI" is that we stole it from Jeff's STS spec, and I found the
 > term made it clear that this is something that may need to be computed
 > from various bits on the wire.

Yes, the latter aspect wrt "..something that may need to be computed from
various bits.." is exactly why I included "effective" in the term when I 
thought it up ("effective request URI").


Julian Reschke <julian.reschke@gmx.de> later proposed..
 >
 > We discussed this in Maastricht, and the conclusion was that effective
 > request URI can be left undefined in this case - I have rephrased the
 > definition accordingly
 > (<http://trac.tools.ietf.org/wg/httpbis/trac/changeset/992>):
 >
 > -- snip --
 > 4.3.  Effective Request URI
 >
 >     HTTP requests often do not carry the absolute URI ([RFC3986], Section
 >     4.3) for the target resource; instead, the URI needs to be inferred
 >     from the request-target, Host header field, and connection context.
 >     The result of this process is called the "effective request URI".
 >     The "target resource" is the resource identified by the effective
 >     request URI.
 >
 >     If the request-target is an absolute-URI, then the effective request
 >     URI is the request-target.
 >
 >     If the request-target uses the path-absolute form or the asterisk
 >     form, and the Host header field is present, 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 a SSL/
 >        TLS-secured TCP connection,
 >
 >     o  the character sequence "://",
 >
 >     o  the authority component, as specified in the Host header field
 >        (Section 9.4), and
 >
 >     o  the request-target obtained from the Request-Line, unless the
 >        request-target is just the asterisk "*".
 >
 >     If the request-target uses the path-absolute form or the asterisk
 >     form, and the Host header field is not present, then the effective
 >     request URI is undefined.
 >
 >     Otherwise, when request-target uses the authority form, the effective
 >     request URI is undefined.
 > -- snip --

Also in Maastricht, we noted that one could use the term "target URI", and I 
noted that we'd want to be sure to use the term "effective" (or equivalent) in 
the definition for it because it is often a constructed thing.

However, there's the consideration of having a term that accurately reflects 
the characteristics of the thing such that people are reminded of them when 
they are wielding the term -- e.g. if you tell some developer in conversation 
"oh, you just get the 'target uri' and blah blah with it...", and then they go 
look at HTTP msgs and the ABNF thereof for 'target URI' and it isn't there. 
Having "effective" in the term helps, IMV, connote/remind that it is a 
constructed thing (and the rules above are fairly complex, making its 
construction nuanced).

Of course, for those who don't want to use a 3-word term as a name for a thing, 
one can acronymize it "ERU" or "ETU", though there's the arguments of there 
already being too many acronyms in the world...

So there's no easy answer, and to some degree its an editorial decision (matter 
of editorial taste and foresight).

My recommendation is to use either "effective request uri (ERU)" or "effective 
target uri (ETU)" after thinking about it since Maastricht, but I could live 
with "target uri".

The latter "ETU" might make sense if "target uri" is already used elsewhere in 
the specs but it doesn't appear to be (or maybe it was and has been replaced by 
ERU)

I personally prefer "effective request uri" because when the term is used, one 
is discussing the (effective) URI conveyed in/by the HTTP request message. I 
can see why one might use "target uri" because it is the URI being "targeted" 
by the request msg (but it sorta seems one level of indirection away 
terminologically...)

HTH,

=JeffH

Received on Wednesday, 8 September 2010 17:47:39 UTC