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