Re: HTTP2 Expression of Interest : Squid

The 100-continue stuff is really poor flow control, from my perspective.
Also, I've yet to meet an implementor who even likes 100-continue because
it messes with the idea of a request-response model. It should be metadata
and was a nasty nasty hack. Phooey! :)

The idea of MGET vs GET amounts to making something optional.

If you do that there will be clients that didn't implement it because
they're lazy.

I have little desire to cater to lazy client implementors and incomplete
spec implementations-- They can stick with HTTP/1.1.
I care strongly about the user and the user experience.
I fight (and create, blah blah) for the users!

If we make this optional, one of these is likely to happen
1) We increase the amount of inlining that people do, because it is the
easiest way to deal with cold page load time, especially for mobile devices.
2) Nobody implements the feature because optional features are often poorly
tested and the cost/benefit causes this to converge in a negative feedback
loop. The feature becomes unused.
3) Latency is worse than it could be across a number of different use
cases, one interesting one is a redirect.

If anyone is under the illusion that the client has any control over what
it receives, I'd like to disabuse them now.
Any content creator can put whatever they want into any resource, making it
whatever size they'd like at any time.
The client gets to decide to call recv() or not. It controls what resource
it requests. That is it, really. It can't call close() unless it wishes to
abandon the resource it is loading which in the inlining case would be the
main resource.

Thusfar with server-push, we're proposing to give the client another knob--
it can tell the server to stop sending stuff it doesn't like. It gives
clients and proxies more flexibility to identify and filter.
It can do so without causing the session to restart, which is important.
Restarting the session is costly in terms of latency to the client, battery
to the device, and CPU to the server.

The idea that the client can announce whether or not it wants a push does
not end with the scenario where the client just gets object A. It results
in a scenario where the client gets object A with mix-ins from B,C,D..N as
unidentifiable, difficult to filter and impossible to  blobs.

Sites and content-providers are not incented to get this wrong, but doing
it the way we have today makes the problem of optimizing pages far, far
more difficult that it should be.


-=R

On Tue, Jul 17, 2012 at 10:17 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

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