RE: HTTP2 Expression of Interest : Squid

I _said_ it was quick and dirty…. There are lots of ways the aesthetics could be cleaned up.

The problem with the single PUSH method approach, IMO, is that it is unlikely that there shalt be one and only one HTTP method with side-effects for ever and ever. Hence, whatever goodness PUSH would have wrt to authentication an long/indefinite entity bodies would have to be duplicated for any new method with similar problems.


From: James M Snell [mailto:jasnell@gmail.com]
Sent: Tuesday, July 17, 2012 5:17 PM
To: Paul Leach
Cc: Julian Reschke; Gabriel Montenegro; Adrien de Croy; Poul-Henning Kamp; Amos Jeffries; ietf-http-wg@w3.org
Subject: Re: HTTP2 Expression of Interest : Squid

AUTH-PUT? Eww... for far too many reasons to list. Using a new method for a revised content-push/expect/continue type of mechanism does make sense, however, as it avoids the type of miscommunication that could happen when attempting to interact with downlevel servers. A single "PUSH" method, as I described previously, with semantics defined strictly for HTTP/2.0 should be enough to address the issue.

- James
On Tue, Jul 17, 2012 at 5:06 PM, Paul Leach <paulle@microsoft.com<mailto:paulle@microsoft.com>> wrote:
Other people have covered most of the issues in other posts.
Also, as RFC 2616 says:
        Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.
Hence, even if HTTP/2.0 creates an ironclad spec, if the first thing the client does is a PUT, the client won’t know that it isn't talking to an HTTP/2.0 server until it is too late.

An quick-and-dirty  example of an approach I had in mind that might work is a new AUTH-* family of methods with a request line that looks like
                AUTH-method Request-URI HTTP/1.1
e.g.
        AUTH-PUT /someresource HTTP/1.1
which will return 401 if authentication would be required if "method" was invoked on the Request-URI, 200 if not, and 501 if the server doesn’t understand the AUTH-* methods.

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>]
Sent: Tuesday, July 17, 2012 10:18 AM
To: Gabriel Montenegro
Cc: Adrien de Croy; Poul-Henning Kamp; Amos Jeffries; ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org>
Subject: Re: HTTP2 Expression of Interest : Squid
On 2012-07-17 19:02, Gabriel Montenegro wrote:
>> From: Adrien de Croy [mailto:adrien@qbik.com<mailto:adrien@qbik.com>]
> ...
>> I agree, and actually I'd be keen to apply this philosphy in both
>> directions, where no significant resource is transmitted in either
>> direction without the recipient indicating prior willingness (either
>> by requesting it, or indicating willingness).  What I'm getting at
>> here is large POST / PUT requests.  Currently it's a mess esp with auth in the mix.
>
> Along these lines, to help with a  POST/PUT with auth in the mix we mentioned an idea in our authentication EoI of a lightweight probe:
>
> http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0239.html:

>
> 1.       Lightweight "probe" for POSTs and PUTs.  Initial PUTs and POSTs with long entity bodies will cause problems because of the extra round trip required by authentication. ("Initial" means when first request on a connection is PUT or POST). If the body is indefinite length, it may not be able to be recreated. This is a problem with any multi-legged authentication scheme in HTTP. It could be avoided if there were a guaranteed benign request type that could be used to force authentication if needed before doing the PUT or POST.

We have

   Expect: 100-continue

for that, no?

Best regards, Julian