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
