4 ms·

I read the whole thing, and I just don't like it. The beauty of HTTP headers, cookies, and elements is their simplicity (or primitivness). They are easy to i

by ardit33 18y ago

I read the whole thing, and I just don't like it. The beauty of HTTP headers, cookies, and elements is their simplicity (or primitivness). They are easy to implement. This proposal will introduce a huge complexity to the HTTP spec. If you have implemented caching in a client, it is so easy for things to go wrong, even if the clients are right, the server, content managers could mess this up roaly really fast. The other thing I don't like, is that when using raw sockets, and try to implement HTTP over it, (many reasons to do this, especially in mobile), now you have to deal with more complexities. As somebody mentioned above, eliminating duplicate http headers, and addressing the duplicity issue in the markup language itself (i.e HTML5 or XHTML2), and not the transport protocol.

ardit33 18y ago
here is somebody's counterpoint: "It seems to me that AJAX can be used to solve this problem in a simpler manner. Take Gmail for example--it downloads the whole UI once and then uses AJAX to get the state-specific data. The example from the PPT showed a 40% reduction in the number of bytes transmitted when using SDCH (beyond what GZIP provided) for google SERPs. I bet you could do about that well just by AJAXifying the SERPs (making them more like GMail) + using regular HTTP cache controls + using a compact, application-specific data format for the dynamic parts of the page + GZIP. Maybe Google's AJAX Search API already does that? In fact, you might not even need AJAX for this; maybe IFRAMEs are enough. I also noticed that this proposal makes the request and response HTTP headers larger in an effort to make entity bodies smaller. It seems over time there is an trend of increasingly large HTTP headers as applications stuff more and more metadata into them, where it is not all that unusual for a GET request to require more than one packet now, especially when longish URI-encoded IRIs are used in the message header. Firefox cut down on the request headers it sends [2] specifically to increase the chances that GET requests are small enough to fit in one packet. Since HTTP headers are naturally highly repetitive (especially for resources from the same server), a mechanism that could compress them would be ideal. Perhaps this could be recast as transport-level compression so that it could be deployed as a TLS/IPV6/IPSEC compression scheme. Regards, Brian "
- litewulf 18y ago
  I assume the main argument against this idea is the burden it places on the Javascript engine. Its the same reason people use gzip and not packer (well, assuming packer produces a smaller file, which happens sometimes). Engines are getting faster, but they still really can't compete with native browser facilities.

by ardit33 18y ago

ardit33 18y ago

here is somebody's counterpoint: "It seems to me that AJAX can be used to solve this problem in a simpler manner. Take Gmail for example--it downloads the whole UI once and then uses AJAX to get the state-specific data. The example from the PPT showed a 40% reduction in the number of bytes transmitted when using SDCH (beyond what GZIP provided) for google SERPs. I bet you could do about that well just by AJAXifying the SERPs (making them more like GMail) + using regular HTTP cache controls + using a compact, application-specific data format for the dynamic parts of the page + GZIP. Maybe Google's AJAX Search API already does that? In fact, you might not even need AJAX for this; maybe IFRAMEs are enough. I also noticed that this proposal makes the request and response HTTP headers larger in an effort to make entity bodies smaller. It seems over time there is an trend of increasingly large HTTP headers as applications stuff more and more metadata into them, where it is not all that unusual for a GET request to require more than one packet now, especially when longish URI-encoded IRIs are used in the message header. Firefox cut down on the request headers it sends [2] specifically to increase the chances that GET requests are small enough to fit in one packet. Since HTTP headers are naturally highly repetitive (especially for resources from the same server), a mechanism that could compress them would be ideal. Perhaps this could be recast as transport-level compression so that it could be deployed as a TLS/IPV6/IPSEC compression scheme. Regards, Brian "

litewulf 18y ago
I assume the main argument against this idea is the burden it places on the Javascript engine. Its the same reason people use gzip and not packer (well, assuming packer produces a smaller file, which happens sometimes). Engines are getting faster, but they still really can't compete with native browser facilities.