- From: mike amundsen <mamund@yahoo.com>
- Date: Thu, 11 Sep 2008 14:01:21 -0400
- To: public-webapps@w3.org
I think a reasonable approach would be to offer an optional flag to *attempt* compression on the upload. When set to "false" (the default), no OPTION call would be made and the content would be sent w/o any compression. When set to "true" the component can make an OPTIONS call, inspect the result and - if the proper HTTP Header is present in the reply, send using the appropriate compression format. Components could choose to not implement this feature, implement it using only one type of compression or implement it w/ the ability to support multiple types of compression. MikeA On Thu, Sep 11, 2008 at 1:50 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> >> 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 >> >> > > > > -- > mca > http://amundsen.com/blog/ > -- mca http://amundsen.com/blog/
Received on Thursday, 11 September 2008 18:01:56 UTC