Re: Support for compression in XHR?

Stewart Brodie wrote:
> Jonas Sicking <jonas@sicking.cc> wrote:
> 
>> Stewart Brodie wrote:
> 
>>> I disagree with any proposal that allows the application layer to
>>> forcibly interfere with the transports layer's internal workings.  Use
>>> of encodings, persistent connections, on-the-fly compression are
>>> entirely internal to the transport mechanism.
>> This is fine for transport mechanism where capability negotiation is 
>> two-way.
>>
>> However a relatively common use case for the web is transferring things 
>> through HTTP, where the HTTP client has no way of getting capability 
>> information about the HTTP server until the full request has already 
>> been made.
> 
> I don't believe that this is the case.  Even in the case where you are using
> a cross-domain request to a server that the client has not talked to before,
> the client always has the option of attempting an OPTIONS request to see
> what the server offers.  It might choose to do that if it's going to have to
> send a large entity-body in the request; it might not bother if the entity
> is small.

Sure, we could make XHR always do an OPTIONS request before sending 
anything to the server. However it seems like this might affect 
performance somewhat.

> The application cannot possibly know that the request isn't going to get
> routed through some sort of transparent proxy - or normal proxy for that
> matter - where your forcing of encoding will fail.  That is why it is a
> transport-level option, not an application-level option.

A transparent proxy shouldn't look at the actual data being transferred, no?

/ Jonas

Received on Thursday, 11 September 2008 17:55:16 UTC