W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: Support for compression in XHR?

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 11 Sep 2008 10:50:58 -0700
Message-ID: <48C95A82.4040908@sicking.cc>
To: Jonas Sicking <jonas@sicking.cc>, Dominique Hazael-Massieux <dom@w3.org>, public-webapps@w3.org, Stewart Brodie <stewart.brodie@antplc.com>

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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:12 UTC