Re: Upload negotiation

Henrik Nordstrom wrote:
> My thinking was more in the line one of the streaming protocols,
> allowing seeking etc without loosing the session, and low initiation
> overhead to deal with the problem of increasing bandwidth but pretty
> much constant rtt..
>
> Current HTTP beats FTP on all aspects, and FTP is likely to decline
> considerably over time.
>
>   
definitely.

>> All doable, but quite different from session-oriented.  It's easy to see 
>> why session-oriented was chosen.  Makes association of interim / 
>> temporary credential handles with a user trivial in most cases.
>>     
>
> What do you refer to here by "session-oriented"?
>
>   
sorry, I meant connection-oriented.

>> I guess that's the thing.  100-continue -> timeout ->start sending is 
>> the optimistic option.
>>     
>
> Yes. You start out by assuming 100 Continue is supported, and the fall
> back gracefully to HTTP/1.0 behaviour if you suspect it's not..
>
> The less we see of HTTP/1.0 in the relevant traffic, the less you need
> to fall back on timeout..
>   
but still relying on either chunking or disconnection, which breaks
connection-based auth.

OK, I'm with you.

>> Could make a SHOULD level requirement that user agents sending chunked 
>> requests that choose to abort them SHOULD include a "0 ; aborted" chunk 
>> extension.
>>     
>
> I would make propose it being a MAY for 1.1, SHOULD or even MUST for
> 1.2.
>   

I hadn't even considered for 1.1, but that would be great.  Very easy to
test for.

>> OK, I'd be happy with anything that can tell me the length.  I'm not 
>> aware of why it can't be Content-Length for client requests (it's more 
>> obvious to me when it comes to server responses), but if it could be 
>> converted to	 a Content-Length header for relaying upstream that solves 
>> spooling and flow-control issues.
>>     
>
> It can't be Content-Length due to interactions with current
> implementations looking for Content-Length to determine the message
> length. Especially if there is HTTP/1.0 hops in the chain..
>   
ah, because we rely on HTTP 1.0 to bounce a POST with no
Content-Length.  HTTP1.1 existing implementations should be ignoring
it.  It would only be new ones that would use both.

But I agree, another field would be better then.

>> I guess this means that proxies have to start caching details of servers 
>> then.
>>     
>
> Yes.
>
>   
:(


>> Problem is that caching things like HTTP versions etc unlike 
>> normal caching in HTTP doesn't have the benefit of explicit cache 
>> support - specified expiries, dates, etc.  There's nothing governing 
>> that caching.
>>     
>
> And it's not very likely servers suddenly downgrade.. How long or how
> many servers to keep track of is an implementation detail based on the
> trust in implementers to use common sense.
>   

now where have I heard that before :)


> Regards
> Henrik
>
>   

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

Received on Tuesday, 8 April 2008 22:18:42 UTC