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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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.

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

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.

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

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUtx7NAAoJELJo5wb/XPRj+qEIANqAXvBFEu46MsJ/57Enn2eK
cwXKP/b2X/DT4l9vuwq5BUZeUjcfgfkoO4WFxyM2lVY2cypT+mElNAIoBy8/LTcI
M/uc1zPMms3eIe5KNDeYgE4mDCtrKbTSPs2+jmvKofwGatp8phBtNv6dIQJ1bKTD
1MCKkUSGsvsAaEkIUB3isOOtUnG+ys7TH79DEAtpCVDqFtVclhMOjOTRXEeDzJVO
x38CXhfVUQiR5d2khujG0KQc/Zk9uDECj5dZla72GKT3asji83rpRLUqd4UdfArv
05tzSaiow/p4y6D+cJV8e1iCP+GVPsyXGLXixUnjQ/qwhh2kcilVNP/zzOO8LTA=
=SNhV
-----END PGP SIGNATURE-----

Received on Thursday, 15 January 2015 01:59:15 UTC