Re: [Fwd: I-D ACTION:draft-decroy-http-progress-00.txt]

Henrik Nordstrom wrote:
> tor 2007-02-15 klockan 12:39 +1300 skrev Adrien de Croy:
>
>   
>> We may have to leave proper (end to end) flow control for HTTP/2.0 then
>>     
>
> And stop calling it flow control. Abandoning the body transfer when one
> is indicated is not flow control.
>
>   
I guess what I'm talking about when I say flow control, is fully 
bilaterally negotiated agreement on sending
of message bodies in either direction.  So separating out the 
transmission of headers, from transmission of body, and
negotiating agreement on whether a body may be transmitted.

when a client makes a request for a server resource, and a server 
responds, that's bilateral.  The client chose to make
the request, and the server can choose not to send a body in the response.

when a client makes a request containing a resource, there is no 
opportunity for negotiation or agreement about
WHEN the transfer of the message body from the client will occur.

Since transmission of the message body may be costly, being able to 
negotiate its transfer is what I'm talking about.

There is normally no negotiation phase in HTTP of course, for 
performance reasons.  A negotiation phase in the case of
clients submitting large request bodies could be useful however.  There 
are mechanisms already to deal with this
which noone uses, such as sending an OPTIONS command first to evaluate 
the server capabilities could be one way to
probe likely outcomes before attempting to submit a large body.  But 
it's not clear how this would be used in this case.

>> Unless we ban it if there's a via header, but many proxies do not insert
>> these for security reasons.
>>     
>
> Well.. specs says they MUST. Nothing except for the HTTP version numbers
> contained therein needs to mean anything however..
>
>   
understood.

>> So if we go back to chunking then, so that any intermediaries can be
>> satisified as to request being completed, then
>> we could still possibly do something about the issue of
>> connection-oriented auth?
>>     
>
> Yes. The scheme I outlined earlier should work in nearly all situations.
> The exception being if the capability of the forwarding path changes
> drastically if the client disconnects and tries again after the initial
> dummy auth challenge. But even then at least for PUT/POST it should fail
> gracefully. For other methods which MAY have a request-body (for example
> GET) the analysis is not so easy, but thankfully a chunked body can not
> be misread as a valid HTTP request so the likelyhood for bad things to
> happen as result of a chunked request being sent to a HTTP/1.0
> proxy/server is quite distant..
>   

understood
.

> The problem with NTLM auth is not so much the 100 Continue timer, but
> the fact that the connection MUST be kept persistent once the client
> "challenge"/capability-negotiation packet has been sent and therefore
> the request body MUST be transmitted. RFC2616 only allows this when
> using chunked (8.2.2 Monitoring Connections for Error Status Messages)
> so to comply with RFC2616 transmission requirements any session using
> NTLM auth MUST use chunked during the handshake until the final
> credentials is sent.
>   
that would solve message / control  synchronisation issues for sure, 
since you could always be sure
of message boundaries.

So maybe this just really needs to be a clarification note to 
implementors on what to do.

e.g use chunking until you get a 100 continue, then send Content-Length 
would be a preferred
way, then the server can still make policy decisions using the entity 
length, and proxies can still
pump through to an upstream HTTP 1.0 entity knowing apriori the length.

I think we're getting somewhere here?

Are there any comments on the proposal about status messages back to the 
client?

there is still the issue about what status is best to be used for this - 
really a purely informational
message is best one which does not induce a state-change in the client.

Regards

Adrien

> Regards
> Henrik
>

Received on Thursday, 15 February 2007 03:23:40 UTC