Re: [IANA #801638] Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

On Jan 14, 2015, at 5:58 PM, Amos Jeffries wrote:
> On 15/01/2015 8:40 a.m., Roy T. Fielding wrote:
>> On Jan 14, 2015, at 12:48 AM, Amos Jeffries wrote:
>> 
>>> On 14/01/2015 12:37 p.m., Roy T. Fielding wrote:
>>>> It should be registered as safe and idempotent (YES to both).
>>>> 
>>>> ....Roy
>>>> 
>>> 
>>> Disagree.
>>> 
>>> Idempotent requires being repeatable. The client is permitted by 
>>> HTTP/2 to pipeline many requests immediately which may affect
>>> the server state with HTTP/2 non-idempotent messages before the
>>> initial SETTINGS arrives from server. PRI is only retriable if
>>> the server response is an HTTP/1.x format error message
>>> indicating an h2 server never got the HTTP/2 payload.
>> 
>> The other requests are not part of the PRI method, which is just 
>> being used to snowplow the connection.  The same snowplowing is 
>> done every time the client opens a new connection to the server. 
>> Hence, the request is repeated and has the same effect every time.
> 
> - From the HTTP/1.1 perspective they are part of its payload, just like
> an hypothetical implementation that does not understand CONNECT would
> treat the tunnel data as part of that methods payload.

No, it wouldn't, since the request message framing is not method
dependent.  The request message ends at the blank line.

> 4.2.1. Safe Methods
> "
>   Of the request methods defined by this specification, the GET, HEAD,
>   OPTIONS, and TRACE methods are defined to be safe.
> "
> 
> Note how CONNECT is not listed as safe. It is likewise omitted from
> the idempotent list.

That's because the semantics of tunnels are not defined to be safe
nor idempotent.  They are simply unknown.  PRI (as used in the h2
preface at "http://tools.ietf.org/html/draft-ietf-httpbis-http2-16#section-3.5")
is known to be both and depends upon it being safe and idempotent.

>>> Safe requires no effect on the server, and implies cacheability.
>> 
>> Neither of those assumptions is true, and in any case the PRI 
>> method being defined does nothing and contains nothing.
> 
> - From a naive HTTP/1.1 servers perspective it "contains" the entire
> HTTP/2 data stream, just like a CONNECT "contains" ("switches to" if
> you prefer) whatever arbitrary protocol is in the tunnel. Due to
> (correct) lack of Content-Length header in the magic.

*sigh* ... RFC7230, sec 3.3:

   The presence of a message body in a request is signaled by a
   Content-Length or Transfer-Encoding header field.  Request message
   framing is independent of method semantics, even if the method does
   not define any use for a message body.

> As to my statement,
> 4.2.1. Safe Methods
> "
>   ... the client does not request, and does
>   not expect, any state change on the origin server as a result of
>   applying a safe method to a target resource.
> ...
>   The purpose of distinguishing between safe and unsafe methods is to
>   allow automated retrieval processes (spiders) and cache performance
>   optimization (pre-fetching) to work without fear of causing harm.
> "
> 
> target resource of PRI parses as being the server ("*").
> 
> To avoid breaking whatever was going on well behaved interception
> intermediaries are required to accept any request with a conforming
> request-line (which this is) and relay unknown ones to the destination
> server.

Interception intermediaries do not implement HTTP.

The asterisk-form "*" is not used in HTTP/1.1 for anything other than
OPTIONS (Section 5.3 of [RFC7230]).  But that doesn't matter in this case
because the protocol is HTTP/2.0 and there is no "destination server"
other than the IP address (no Host, no full URI, nowhere else to go).
If the intermediary is smart enough to have read the HTTP method
registration flag for a previously unknown method and to make code
pathway assumptions based on that, then it had better be looking at
the protocol version as well (since method semantics can be changed
with major protocol revisions).

>> Whatever else that is sent on the connection after the initial PRI
>> message is irrelevant to the semantics of the PRI message, which is
>> to do nothing but cause an abort (hopefully with 405) from
>> non-compliant recipients.
> 
> A only 1.1-compliant recipient will abort it due to 405 or 505
> conditions on arrival. Safe and Idempotent situations will never be
> reached.
> 
> The unsafe/non-idempotent is for intermediaries in the naive case
> which relay unknown request-lines transparently to a server.

No.  While that may be your focus and why you choose to interpret
their use, the definitions have no dependency at all on intermediaries.
An intermediary must relay unknown methods unless it has been specifically
configured not to do so, regardless of the safe or idempotent flags,
because failing to do so will block extensibility.  That has no relevance
to an intermediary that does know the PRI method well enough to know
whether it has been flagged as safe, in which case it would be absolutely
moronic for said implementation to go ahead and forward it given that
the message it is forwarding is not even HTTP/1.1.

> This may
> be from admin configuration on forward/reverse proxies or TCP IP
> details on interceptors.
> In that case HTTP/1.1 headers (ie Transfer-Encoding:chunked) and
> version label may be added by the intermediary. Which immediately
> breaks any receiving 1.1 implementations from being able to 405/505
> the method.

Honestly, I can't begin to explain how many other things that would break.
Generally speaking, intermediaries that make shit up when forwarding
request messages for which they don't even speak the protocol are already so
hopelessly broken that I would rather have the data center catch fire
and explode than attempt to rationalize their existence.

> The intent when I requested this get registered was to aid HTTP/1
> implementers who see it as a method occuring but not implementing or
> understanding enough HTTP/2 to handle it correctly. There is a lot of
> complex (and useless) code pathways that can be simply skipped in
> HTTP/1 implementations only if it is treated as both Unsafe and
> non-Idempotent. All of which aids HTTP/2 performance and transit over
> non-HTTP/2 aware intermediaries.
> ** The cases where it can be treated as safe or idempotent without
> side effects by an intermediary require developers have enough HTTP/2
> knowledge to safely identify those cases and do the processing properly.
> 
> Amos

The method is being registered as a defense against others using the
same method name for something totally different.  This is reserving the
name.  It isn't going to be registered incorrectly just because of a
code pathway that theoretically might exist on some future not-yet-implemented
and non-HTTP-compliant interception proxy.  The obvious fix for such a
code pathway is the HTTP-version, rather than falsely stating the simple
answers to the two mathematical definitions in the out-of-band registration
flags of a method that is never supposed to be implemented.

....Roy

Received on Friday, 23 January 2015 22:13:42 UTC