- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 11 Sep 2008 11:19:33 -0700
- To: mike amundsen <mca@amundsen.com>
- CC: public-webapps@w3.org
mike amundsen wrote: > 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. Wouldn't a better solution then be that when the flag is set always compress? And leave it up to the application to ensure that it doesn't enable capabilities that the server doesn't support. After all, it's the applications responsibility to know many other aspects of server capabilities, such as if GET/POST/DELETE is supported for a given URI. Or is there a concern that there is a transparent proxy sitting between the browser and the server that isn't able to deal with the compression? If so, will the OPTIONS proposal really help? If it will, how? / Jonas
Received on Thursday, 11 September 2008 18:21:50 UTC