RE: HTTP2 Expression of Interest : Squid

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] 
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
Subject: Re: HTTP2 Expression of Interest : Squid

On 2012-07-17 19:02, Gabriel Montenegro wrote:
>> From: Adrien de Croy [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

Received on Wednesday, 18 July 2012 00:06:57 UTC