On Tue, 4 Feb 2003, bdonlan wrote: > > 2.1) We care about supporting browsers thad don't support gzip compressed > > pages. Therefore, there is a requirement for a gzip decompressor in > > fproxy, so that it can uncompress the document for the browser that > > doesn't support the standard compression method. Fproxy decompresses the > > gzipped document, omits the Content-Encoding header, and passes back the > > plain text file. > > There's an easy-to-use Java class for gzip decoding/encoding built into the > Jave Runtime classes, but this would break compatibility. Maybe support for > reading them could be added, then on the next forced upgrade add default > compression?
It would break compatibility ONLY if it was used. It would be up to the site authors to decide for themselves if they were more interested in performance or compatibility. The difference is that the file would potentially come down as gzipped without the Content-Encoding header being set. Obviously, this would come up as garbage in the browser. > > 2.2) We DON'T care about browsers that don't support the gzip encoding. > > This is probably safe, because all commonly used browsers support this. In > > this case, the fproxy modifications would be much smaller. All it would > > have to do is look up the compression encoding on the file in the headers > > once it has downloaded it to the local node, and if set to "gzip", it > > would only have to pass back the standard headers, add the > > "Content-Encoding: gzip" header, and pass back the compressed file. It > > would only have to look up the file encoding, and set a header > > accordingly. > > Violates HTTP protocol by ignoting the Accept-Encoding header. No it doesn't. You don't have to gzip the response payload just because the browser supports it. The problem is that you could potentially be sending the data back gzipped when the browser hasn't declared it's ability to understand the gzipped content. Yes, it does break the strict HTTP compatibility, but then again, fproxy doesn't support HEAD requests either, which I would consider to be a much more serious compatibility issue. > > Obviously, changes to the insertion tools would be required, too... > > They *should* use freenet.client.*, but most don't. Those that do could be > easily updated by updating the instertion classes in freenet.jar. Hmm... In that case that shouldn't be as big a change as I initially thought. The issue there is do you then compress each file by default, provided it is of a compressible MIME type (obviously, there is no point in compressing a zip file)? Or do you leave it to the user to compress each file separately before they upload it? The advantage of transparently compressing each file before the upload is that it would make a site easier to test locally becure uploading it. But there is still the choice between doing it in the uploader program or in the node itself... Initially I thought about it as an optional, manual operation, but now I am leaning toward the benefits of the transparent operation. Regards. Gordan _______________________________________________ Tech mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org:8080/cgi-bin/mailman/listinfo/tech
