Re: Support for compression in XHR?
On Sep 11, 2008, at 22:59, Jonas Sicking wrote: Wouldn't a better solution then be that when the web page sets the flag on the XHR object the browser will always compress the data? And leave it up to the web page to ensure that it doesn't enable capabilities that the web server doesn't support. After all, it's the web page's responsibility to know many other aspects of server capabilities, such as if GET/POST/DELETE is supported for a given URI. This is the approach I've taken with Validator.nu. Validator.nu support gzipped request bodies. If someone reads the docs for the Web service API so that they can program client code for the service, they should notice what the documentation says about compression. There is, though, the problem that now compression support is part of the published API as opposed to being an orthogonal transport feature, so removing incoming compression support from Validator.nu (e.g. if bandwidth were abundant and CPU were the bottle neck) would break existing clients. This is not a problem with same-site XHR, though, when the same entity controls the server and the JS program performing the requests and can update the JS program immediately. (Validator.nu also advertises Accept-Encoding: gzip via OPTIONS, but I'm not aware of any client automatically picking it up from there.) -- Henri Sivonen [EMAIL PROTECTED] http://hsivonen.iki.fi/
Re: Support for compression in XHR?
Jonas Sicking [EMAIL PROTECTED] wrote: This at the cost of the overhead of always making an OPTIONS request before attempting compression. Only if you haven't seen the server before - and in the vast majority of cases, you will have. I wouldn't suggest sending it every time, because that would be clearly daft. Typically, HTTP clients need to maintain notes on servers if they want to work optimally with them anyway. Whether the server supports compression via gzip and/or deflate would just be another bit of information that the client could collect. -- Stewart Brodie
Re: Support for compression in XHR?
Stewart Brodie wrote: Jonas Sicking [EMAIL PROTECTED] 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
Re: Support for compression in XHR?
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 [EMAIL PROTECTED] wrote: Stewart Brodie wrote: Jonas Sicking [EMAIL PROTECTED] 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/
Re: Support for compression in XHR?
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
Re: Support for compression in XHR?
Jonas: Good points. 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. My assumption here is that component = XHR and application = browser (or some other hosting environment). If, in reality, it is the application that is making the HTTP Requests when using the XHR component, then yes, it is reasonable for the application to handle any OPTIONS calls and negotiating of compression capabilities. And, if the app-level is doing this, XHR can signal compression is to be used when the flag is turned on and let the app-level sort it out. 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? I'm pretty sure the Accept-Encoding HTTP Header is transport-level (not hop-by-hop). If it is, then proxies should not be an issue. Also, my suggestion of using OPTIONS for server to advertise support for inbound compression is not standard. In fact, using Accept-Encoding from the server side might be a misuse of the header. It was just a way to get things started. MikeA On Thu, Sep 11, 2008 at 2:19 PM, Jonas Sicking [EMAIL PROTECTED] wrote: 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 -- mca http://amundsen.com/blog/
Re: Support for compression in XHR?
If i understand you, you're saying the coding of the page (HTML/JS) should 'know' that the target server does/does-not support compression for uploads and handle it accordingly. I assume you mean, for example, as a coder, I know serverX only allows posting an XML document, while serverY only allows posting urlencoded pairs; therefore I write my HTML page accordingly to prevent errors. This works fine and is the way most pages are built today. I was thinking that compression on upload could be seen more like compression on download. This is a decision that HTML/JS coders do not have to make as it is handled 'under the covers' between client and server. When clients make a request, they tell the server that they can accept compressed bodies. If the server is properly config'ed/coded it can then compress the response. and if the server does not support compressed downloads, it just sends the uncompressed version instead. no handshakes. no extra traffic. In my initial suggestion was attempting to describe a way that the client could act the same way for up-stream bodies. Maybe we don't need any flags at all. If the environment (app code, browser, component?) 'knows' the server supports compressed uploads, it sends the body that way. I just am not clear on the details of how to support this cleanly without causing extra traffic or breaking existing implementations. Ideally, I think some thing like this is transport-level and should be 'serendipitous' if at all possible instead of requiring special coding on the client. MikeA snip My assumption here is that component = XHR and application = browser (or some other hosting environment). Sorry, in my initial reply I meant application as the one that has specific knowledge of the data and servers that are being involved. In this case that means the webpage. I'll try to clarify: / Jonas /snip -- mca http://amundsen.com/blog/
Re: Support for compression in XHR?
mike amundsen wrote: If i understand you, you're saying the coding of the page (HTML/JS) should 'know' that the target server does/does-not support compression for uploads and handle it accordingly. I assume you mean, for example, as a coder, I know serverX only allows posting an XML document, while serverY only allows posting urlencoded pairs; therefore I write my HTML page accordingly to prevent errors. This works fine and is the way most pages are built today. Yup. I was thinking that compression on upload could be seen more like compression on download. This is a decision that HTML/JS coders do not have to make as it is handled 'under the covers' between client and server. When clients make a request, they tell the server that they can accept compressed bodies. If the server is properly config'ed/coded it can then compress the response. and if the server does not support compressed downloads, it just sends the uncompressed version instead. no handshakes. no extra traffic. This would be idea. I definitely agree. In my initial suggestion was attempting to describe a way that the client could act the same way for up-stream bodies. Maybe we don't need any flags at all. If the environment (app code, browser, component?) 'knows' the server supports compressed uploads, it sends the body that way. I just am not clear on the details of how to support this cleanly without causing extra traffic or breaking existing implementations. Your proposal with the flag seems like it's reverting to the having to know case, since you'd want to set the flag if and only if the server supports compression to avoid extra overheads, while still taking advantage of compression when the server supports it. Ideally, I think some thing like this is transport-level and should be 'serendipitous' if at all possible instead of requiring special coding on the client. Agreed. I personally just can't think of such a solution. However there are people far smarter than me and with far more knowledge of HTTP on this list, so hopefully we can figure something out. / Jonas
Re: Support for compression in XHR?
Jonas: snip Your proposal with the flag seems like it's reverting to the having to know case, since you'd want to set the flag if and only if the server supports compression to avoid extra overheads, while still taking advantage of compression when the server supports it. /snip Well, seems I've muddled things a bit by mixing concerns of cross-domain, compression support, and security in an overly simple suggestion. My intention was to allow clients to decide if they want to *attempt* compression, not *force* it. Thus, it could be exposed as an flag in the component in an effort to cut down on extra traffic between client and server. If the flag is set to false, don't try query the server to see if it supports compression. This is on the assumption that a client must execute an OPTIONS call in order to discover if the server supports compression on uploads. This model would make the whole conversation transparent to the application developer, but not the component developer. I agree that a better process would be to engineer it in a way that makes this discovery and choice transparent to the component developer, too. One way to do this would be to engineer the component to send the body using the compression method described by the X-Accept-Compression-For-Upload header when present. If the header does not exist, no problem. If it does, inspect it for a compression format supported by the component and, if one is found, do the compression. With this approach all that is needed is that the server agrees to send the header to the client (on every request? on OPTIONS request?) and the component agrees to look for it and honor it if possible. No flags. No extra traffic. Finally, in the case of *X*HR, this header might be allowed automatically, ignored all the time, or require a pre-flight. That is probably a different discussion. MikeA On Thu, Sep 11, 2008 at 8:20 PM, Jonas Sicking [EMAIL PROTECTED] wrote: mike amundsen wrote: If i understand you, you're saying the coding of the page (HTML/JS) should 'know' that the target server does/does-not support compression for uploads and handle it accordingly. I assume you mean, for example, as a coder, I know serverX only allows posting an XML document, while serverY only allows posting urlencoded pairs; therefore I write my HTML page accordingly to prevent errors. This works fine and is the way most pages are built today. Yup. I was thinking that compression on upload could be seen more like compression on download. This is a decision that HTML/JS coders do not have to make as it is handled 'under the covers' between client and server. When clients make a request, they tell the server that they can accept compressed bodies. If the server is properly config'ed/coded it can then compress the response. and if the server does not support compressed downloads, it just sends the uncompressed version instead. no handshakes. no extra traffic. This would be idea. I definitely agree. In my initial suggestion was attempting to describe a way that the client could act the same way for up-stream bodies. Maybe we don't need any flags at all. If the environment (app code, browser, component?) 'knows' the server supports compressed uploads, it sends the body that way. I just am not clear on the details of how to support this cleanly without causing extra traffic or breaking existing implementations. Your proposal with the flag seems like it's reverting to the having to know case, since you'd want to set the flag if and only if the server supports compression to avoid extra overheads, while still taking advantage of compression when the server supports it. Ideally, I think some thing like this is transport-level and should be 'serendipitous' if at all possible instead of requiring special coding on the client. Agreed. I personally just can't think of such a solution. However there are people far smarter than me and with far more knowledge of HTTP on this list, so hopefully we can figure something out. / Jonas -- mca http://amundsen.com/blog/
Re: Support for compression in XHR?
mike amundsen wrote: Jonas: snip Your proposal with the flag seems like it's reverting to the having to know case, since you'd want to set the flag if and only if the server supports compression to avoid extra overheads, while still taking advantage of compression when the server supports it. /snip Well, seems I've muddled things a bit by mixing concerns of cross-domain, compression support, and security in an overly simple suggestion. My intention was to allow clients to decide if they want to *attempt* compression, not *force* it. Thus, it could be exposed as an flag in the component in an effort to cut down on extra traffic between client and server. If the flag is set to false, don't try query the server to see if it supports compression. This is on the assumption that a client must execute an OPTIONS call in order to discover if the server supports compression on uploads. This model would make the whole conversation transparent to the application developer, but not the component developer. What does client, component and application mean in the above paragraph? / Jonas
Re: Support for compression in XHR?
Jonas: In the text below I meant: client = browser (or other hosting environment) component = xmlHttpRequest (or XHR, etc.) object available as part of the client/environment application = code running within the client/environment (i.e. script that can get an instance of the component, etc.) Mike A On Thu, Sep 11, 2008 at 11:01 PM, Jonas Sicking [EMAIL PROTECTED] wrote: mike amundsen wrote: Jonas: snip Your proposal with the flag seems like it's reverting to the having to know case, since you'd want to set the flag if and only if the server supports compression to avoid extra overheads, while still taking advantage of compression when the server supports it. /snip Well, seems I've muddled things a bit by mixing concerns of cross-domain, compression support, and security in an overly simple suggestion. My intention was to allow clients to decide if they want to *attempt* compression, not *force* it. Thus, it could be exposed as an flag in the component in an effort to cut down on extra traffic between client and server. If the flag is set to false, don't try query the server to see if it supports compression. This is on the assumption that a client must execute an OPTIONS call in order to discover if the server supports compression on uploads. This model would make the whole conversation transparent to the application developer, but not the component developer. What does client, component and application mean in the above paragraph? / Jonas -- mca http://amundsen.com/blog/
Re: Support for compression in XHR?
mike amundsen wrote: Jonas: In the text below I meant: client = browser (or other hosting environment) component = xmlHttpRequest (or XHR, etc.) object available as part of the client/environment application = code running within the client/environment (i.e. script that can get an instance of the component, etc.) Mike A On Thu, Sep 11, 2008 at 11:01 PM, Jonas Sicking [EMAIL PROTECTED] wrote: mike amundsen wrote: Jonas: snip Your proposal with the flag seems like it's reverting to the having to know case, since you'd want to set the flag if and only if the server supports compression to avoid extra overheads, while still taking advantage of compression when the server supports it. /snip Well, seems I've muddled things a bit by mixing concerns of cross-domain, compression support, and security in an overly simple suggestion. My intention was to allow clients to decide if they want to *attempt* compression, not *force* it. Thus, it could be exposed as an flag in the component in an effort to cut down on extra traffic between client and server. Wouldn't that mean that it's the application (i.e. web page) and not the client (i.e. browser) that decides to attempt compression or not? I.e. the browser wouldn't try unless the web page had told it to do so. If the flag is set to false, don't try query the server to see if it supports compression. This is on the assumption that a client must execute an OPTIONS call in order to discover if the server supports compression on uploads. This model would make the whole conversation transparent to the application developer, but not the component developer. Not really though, since it's the application (i.e. web page) that needs to set the flag in order to get compression. It seems like the difference between having the web page fully decide and what you are proposing is basically the ability to fall back gracefully if the web page thought that compression is available when it is not. This at the cost of the overhead of always making an OPTIONS request before attempting compression. (not saying if this is good or not, just trying to make sure I understand the proposal). / Jonas
Re: Support for compression in XHR?
Jonas: snip Wouldn't that mean that it's the application (i.e. web page) and not the client (i.e. browser) that decides to attempt compression or not? I.e. the browser wouldn't try unless the web page had told it to do so. /snip Yes, if a flag is employed, the application code is in control. Again, I proposed the flag as a way to by-pass any extra traffic (OPTIONS call) to the server before starting the upload. Because I assumed the OPTIONS call would be required in order to support compressing uploaded bodies. This maybe a poor assumption on my part. snip It seems like the difference between having the web page fully decide and what you are proposing is basically the ability to fall back gracefully if the web page thought that compression is available when it is not. /snip Yes. snip This at the cost of the overhead of always making an OPTIONS request before attempting compression. (not saying if this is good or not, just trying to make sure I understand the proposal). /snip Again, my assumption of the need for OPTIONS may one of the serious flaws in initial my proposal. If determining compression for uploads is handled the same way determining compression for response bodies, then no OPTIONS call would be needed. What about this as a new proposal: When handling the upload of a file, the HTTP Headers collection (sent by the server to the client) for the X-Accept-Compression-for-Upload header. If it exists, the header is parsed to see if a compression format supported by the client is present in the header. If one is present, the file is compressed using that format when it is sent to the server. If no supported format is found or the header is not present, the file is sent to the server without any compression. No flags. No OPTIONS call. Mike A
Re: Support for compression in XHR?
On Wed, Sep 10, 2008 at 7:10 AM, Kris Zyp [EMAIL PROTECTED] wrote: You are using an applet on the server to decode request entities sent from the browser? by applet, i just mean something that does work but isn't the server itself, i don't mean java (typically i'm using perl) Are you saying that you think there is a web server that advertises support for alternate decodings of content encodings in request entities, but then doesn't support it? no, i'm wondering how many advertise support at all, and then if there are some web sites where an applet (see above) handles such things even though the server itself doesn't advertise or support them.
Re: Support for compression in XHR?
Kris Zyp wrote: I suspect compression from the UA to the server will need support on the XHR object in order to work. I don't think the right way to do it is through setRequestHeader though, that seems like a hack at best. I would have thought this would be negotiated by the server sending a Accept-Encoding header to indicate what forms of encoding it could handle for request entities. XHR requests are almost always proceeded by a separate response from a server (the web page) that can indicate the server's ability to decode request entities. I think that this would go against the spirit of HTTP. The idea of HTTP is that it is state-less, so you should not carry state from one request to the next. Encoding capability isn't really a state in the HTTP sense, since it is presumably an immutable characteristic of the server, rather than a mutable state of an application (the latter being what HTTP abhors). It seems completely analagous to Accept-Ranges which works exactly the same (communicates the server's ability to handle Range requests and what range units are acceptable). You might be right, I'd have to defer to people that know HTTP better than me. I'm not sure it's a capability of the server, but rather a capability of that particular URI. For example example.com/foo.cgi might be implemented using entirely different code from example.com/bar.php. / Jonas
Support for compression in XHR?
Hello WebApps WG, The Mobile Web Best Practices Working Group is interested to know whether XmlHTTPRequest has any actual or planned support for compression - I looked quickly in the specs and issues list, but didn't find anything relevant. Thanks, Dom
Re: Support for compression in XHR?
Dominique Hazael-Massieux wrote: The Mobile Web Best Practices Working Group is interested to know whether XmlHTTPRequest has any actual or planned support for compression HTTP has Content-Encoding and Transfer-Encoding, no? No special effort on the part of XMLHttpRequest is needed to make use of those, as long as the underlying HTTP implementation supports them. -Boris
Re: Support for compression in XHR?
Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit : HTTP has Content-Encoding and Transfer-Encoding, no? No special effort on the part of XMLHttpRequest is needed to make use of those, as long as the underlying HTTP implementation supports them. Well, at least when an outgoing XmlHttpRequest goes with a body, the spec could require that upon setting the Content-Encoding header to gzip or deflate, that the body be adequately transformed. Or is there another e.g. to POST a gzip request with Content-Encoding? Dom
Re: Support for compression in XHR?
On 9 Sep 2008, at 14:58, Dominique Hazael-Massieux wrote: Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit : HTTP has Content-Encoding and Transfer-Encoding, no? No special effort on the part of XMLHttpRequest is needed to make use of those, as long as the underlying HTTP implementation supports them. Well, at least when an outgoing XmlHttpRequest goes with a body, the spec could require that upon setting the Content-Encoding header to gzip or deflate, that the body be adequately transformed. Or is there another e.g. to POST a gzip request with Content-Encoding? Why can it not just be added transparently by the XHR implementation? -- Geoffrey Sneddon http://gsnedders.com/
Re: Support for compression in XHR?
Le mardi 09 septembre 2008 à 17:37 +0200, Anne van Kesteren a écrit : On Tue, 09 Sep 2008 17:29:03 +0200, Dominique Hazael-Massieux [EMAIL PROTECTED] wrote: I'm sure it could, but if one implementation does it and another doesn't, this leads to interoperability problems - hence the usefulness of documenting it in the spec. Or this is there any catchall requirements in the spec that covers it? The specification states that user agents SHOULD set the Accept-Encoding header and also states that encoded content MUST be decoded. But that's only relevant when receiving data, not sending it, isn't it? Dom
Re: Support for compression in XHR?
Dominique Hazael-Massieux [EMAIL PROTECTED] wrote: Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit : HTTP has Content-Encoding and Transfer-Encoding, no? No special effort on the part of XMLHttpRequest is needed to make use of those, as long as the underlying HTTP implementation supports them. Well, at least when an outgoing XmlHttpRequest goes with a body, the spec could require that upon setting the Content-Encoding header to gzip or deflate, that the body be adequately transformed. Or is there another e.g. to POST a gzip request with Content-Encoding? 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. If you want to allow hints that the UA can ignore, that's fine - but require is silly - it might make the data larger, for all you know. Leave it as a QoI issue for the user agent to sort this out for itself. -- Stewart Brodie
Re: Support for compression in XHR?
Geoffrey Sneddon wrote: On 9 Sep 2008, at 14:58, Dominique Hazael-Massieux wrote: Le mardi 09 septembre 2008 à 09:02 -0400, Boris Zbarsky a écrit : HTTP has Content-Encoding and Transfer-Encoding, no? No special effort on the part of XMLHttpRequest is needed to make use of those, as long as the underlying HTTP implementation supports them. Well, at least when an outgoing XmlHttpRequest goes with a body, the spec could require that upon setting the Content-Encoding header to gzip or deflate, that the body be adequately transformed. Or is there another e.g. to POST a gzip request with Content-Encoding? Why can it not just be added transparently by the XHR implementation? I doubt that it could. An UA implementation won't know which encodings the server supports. I suspect compression from the UA to the server will need support on the XHR object in order to work. I don't think the right way to do it is through setRequestHeader though, that seems like a hack at best. / Jonas
Re: Support for compression in XHR?
Well, at least when an outgoing XmlHttpRequest goes with a body, the spec could require that upon setting the Content-Encoding header to gzip or deflate, that the body be adequately transformed. Or is there another e.g. to POST a gzip request with Content-Encoding? Why can it not just be added transparently by the XHR implementation? I doubt that it could. An UA implementation won't know which encodings the server supports. I suspect compression from the UA to the server will need support on the XHR object in order to work. I don't think the right way to do it is through setRequestHeader though, that seems like a hack at best. I would have thought this would be negotiated by the server sending a Accept-Encoding header to indicate what forms of encoding it could handle for request entities. XHR requests are almost always proceeded by a separate response from a server (the web page) that can indicate the server's ability to decode request entities. However, the HTTP spec is rather vague about whether it can used in this way (server providing a header to indicate encoding for requests, rather than the typical usage of a client providing the header to indicate encoding for responses), but it certainly seems like it should be symmetrical. Perhaps this vagueness is why no browser has ever implemented such compression, or maybe it is due to lack of demand? IMO, a server provided Accept-Encoding header would be the best way to encourage a browser to compress a request. Accept-Encoding: gzip;q=1.0, identity; q=0.5 Perhaps we should talk to the HTTP group about clarifying the specification. Kris
Re: Support for compression in XHR?
Kris Zyp wrote: Well, at least when an outgoing XmlHttpRequest goes with a body, the spec could require that upon setting the Content-Encoding header to gzip or deflate, that the body be adequately transformed. Or is there another e.g. to POST a gzip request with Content-Encoding? Why can it not just be added transparently by the XHR implementation? I doubt that it could. An UA implementation won't know which encodings the server supports. I suspect compression from the UA to the server will need support on the XHR object in order to work. I don't think the right way to do it is through setRequestHeader though, that seems like a hack at best. I would have thought this would be negotiated by the server sending a Accept-Encoding header to indicate what forms of encoding it could handle for request entities. XHR requests are almost always proceeded by a separate response from a server (the web page) that can indicate the server's ability to decode request entities. I think that this would go against the spirit of HTTP. The idea of HTTP is that it is state-less, so you should not carry state from one request to the next. / Jonas
Re: Support for compression in XHR?
I suspect compression from the UA to the server will need support on the XHR object in order to work. I don't think the right way to do it is through setRequestHeader though, that seems like a hack at best. I would have thought this would be negotiated by the server sending a Accept-Encoding header to indicate what forms of encoding it could handle for request entities. XHR requests are almost always proceeded by a separate response from a server (the web page) that can indicate the server's ability to decode request entities. I think that this would go against the spirit of HTTP. The idea of HTTP is that it is state-less, so you should not carry state from one request to the next. Encoding capability isn't really a state in the HTTP sense, since it is presumably an immutable characteristic of the server, rather than a mutable state of an application (the latter being what HTTP abhors). It seems completely analagous to Accept-Ranges which works exactly the same (communicates the server's ability to handle Range requests and what range units are acceptable). Kris
Re: Support for compression in XHR?
On Wed, Sep 10, 2008 at 2:35 AM, Kris Zyp [EMAIL PROTECTED] wrote: Encoding capability isn't really a state in the HTTP sense, since it is presumably an immutable characteristic of the server, do you really know this? i could have an applet/script/application which handles decoding of gz... i think a survey of major sites and most web servers would be appropriate (there are about 100 web servers [and don't forget to get most deployed versions not just the latest and buggiest], have fun) i'm speaking as someone who writes a bunch of applications which run on fairly anemic webservers. i tend to implement just about everything myself. (I have other hats including mobile hats, but this message was not written with them on) rather than a mutable state of an application (the latter being what HTTP abhors). It seems completely analagous to Accept-Ranges which works exactly the same (communicates the server's ability to handle Range requests and what range units are acceptable).
Re: Support for compression in XHR?
Encoding capability isn't really a state in the HTTP sense, since it is presumably an immutable characteristic of the server, do you really know this? i could have an applet/script/application which handles decoding of gz... You are using an applet on the server to decode request entities sent from the browser? Besides being very strange, why does that have any impact the server's ability to honestly advertise it's services? i think a survey of major sites and most web servers would be appropriate (there are about 100 web servers [and don't forget to get most deployed versions not just the latest and buggiest], have fun) Are you saying that you think there is a web server that advertises support for alternate decodings of content encodings in request entities, but then doesn't support it? Can you think of what they might alternately have intended by including the Accept-Encoding header? Kris
Indicating acceptable request entity encodings (was Re: Support for compression in XHR?)
(Restating for the HTTP working group) Is it reasonable for a server to indicate support for decoding additional content encodings of the request entity body with the Accept-Encoding header? That is, can a server advertise support for decoding gzip in responses, such that a user agent could compress subsequent request entity-body using content-encodings supported by the server? Can a server include a response header: Accept-Encoding: gzip;q=1.0, identity; q=0.5 And then a user agent could compress request entity bodies (and include the corresponding Content-Encoding header). RFC 2616 does not seem to prohibit the use of Accept-Encoding in response headers, but on the otherhand, it only seems to suggest it's use for requests, so it is unclear to me if it is usable in this manner. The use of Accept-Encoding in response headers seems analogous to the Accept-Ranges response header as far advertising the capabilities of a server and seems like an appropriate application of this header to me. Thanks, Kris - Original Message - From: Jonas Sicking [EMAIL PROTECTED] To: Kris Zyp [EMAIL PROTECTED] Cc: Geoffrey Sneddon [EMAIL PROTECTED]; Dominique Hazael-Massieux [EMAIL PROTECTED]; Boris Zbarsky [EMAIL PROTECTED]; public-webapps@w3.org Sent: Tuesday, September 09, 2008 5:00 PM Subject: Re: Support for compression in XHR? Kris Zyp wrote: Well, at least when an outgoing XmlHttpRequest goes with a body, the spec could require that upon setting the Content-Encoding header to gzip or deflate, that the body be adequately transformed. Or is there another e.g. to POST a gzip request with Content-Encoding? Why can it not just be added transparently by the XHR implementation? I doubt that it could. An UA implementation won't know which encodings the server supports. I suspect compression from the UA to the server will need support on the XHR object in order to work. I don't think the right way to do it is through setRequestHeader though, that seems like a hack at best. I would have thought this would be negotiated by the server sending a Accept-Encoding header to indicate what forms of encoding it could handle for request entities. XHR requests are almost always proceeded by a separate response from a server (the web page) that can indicate the server's ability to decode request entities. I think that this would go against the spirit of HTTP. The idea of HTTP is that it is state-less, so you should not carry state from one request to the next. / Jonas
