Fri 08 Nov 2013 10:21:14 AM UTC, comment #4:
Hi Werner,
Ok, I won't discuss further about RFC 2616 and such. But let me say, at least, that Accept-Encoding/Content-Encoding is the common practice and de facto standard:
http://en.m.wikipedia.org/wiki/HTTP_compression
In any case, I will answer your practical questions about my patch as best as I can:
"Please try: Copy compressed files (different compression formats and different file extensions) to your davfs2 file system...":
I have already made many tests of this kind (I wouldn't have dared to submit you a patch otherwise!). I will put you one example of my tests:
# mount via davfs2 (zlib patched).
% mount https://myserver.dom.ain/userdir /home/localuser/Dav/userdir
# make a local copy to a "disk" filesystem (so that every file is "GET" from server).
% cp -apvi /home/localser/Dav/userdir /var/tmp/userdir-davfs2
# make a direct copy from the server (using rsync, scp, choose your weapons...)
% rsync -auv user@myserver.dom.ain:/real/path/to/userdir/. /var/tmp/userdir-rsync
# tell me any difference excluding .DAV files (generated by the DAV-server itself to keep DAV information in it)
# and the lost+found dir generated by the local system.
% diff --recursive --exclude=lost+found --exclude=.DAV /var/tmp/userdir-davfs2 /var/tmp/userdir-rsync
# nothig is reported, the copy is EXACT, byte by byte, as it MUST be.
The content of "userdir" is a mix of files, text, images, and compressed content:
% ls -1s /home/localser/Dav/userdir
95 aa2.txt
571 AdministrationGuidePatchPro2.2.pdf
3 autoexpect.gz
1 lost+found
1 mod_userinfo
14 start-here.png
And I can show you the log of the server where it shows how some files are transferred:
#Format:
# "REQUEST" RESPONSE-CODE RESPONSE-LENGTH [ORIGINAL-LENGTH/COMPRESSED-LENGTH (COMPRESSION LEVEL)]
"GET /userdir/aa2.txt HTTP/1.1" 200 11539 [96764/11521 (11%)]
"GET /userdir/autoexpect.gz HTTP/1.1" 200 2718 [-/- (-%)]
"GET /userdir/start-here.png HTTP/1.1" 200 13938 [-/- (-%)]
"GET /userdir/AdministrationGuidePatchPro2.2.pdf HTTP/1.1" 200 480404 [584206/480386 (82%)]
So aa2.txt (a plain text file) has been transferred compressed saving almost 90% of network use; autoexpect.gz and start-here.png are transferred without compressing; and AdministrationGuidePatchPro2.2.pdf is compressed (saving only a 20%). mod_userinfo is a directory (with a bunch of files of serveral types).
And remember, independently of the original content and of the way they are transferred, the result is an exact copy of the original files.
"What are the server side rules to decide whether to send "Content-Encoding: gzip" or not?"
It doesn't matter to the client: if the client asks for compression (Accept-Encoding) the sever CAN send the response body compressed (sending a Content-Encoding header). Anyway, the client MUST decompress if (AND ONLY IF) the server tells it to do so. The client shouldn't try to guess the content-type, just follow the protocol.
A really bad configured server could compress-encode everything it sends to a client that asks for compress-encoding: it would be a waste of time, bandwith & CPU, but protocol-compliant.
Usually, a real world sever is normally configured in either of two ways:
a) ONLY compress some kind of content (text, html, javascript, etc).
b) COMPRESS anything except some kind of content: (images, videos, music, gzip, zip, bzip2, ...)
In any case, a well behaved server only compress-encodes the response when the client asks for it.
You can use wget (or curl, etc) to see how this happens:
a) A client that does not want compression:
% wget --debug - https://myserver.dom.ain/userdir/aa2.txt
---request begin---
GET /userdir/aa2.txt HTTP/1.1
User-Agent: Wget/1.13.4 (linux-gnu)
Accept: /
Host: chest.iri.upc.edu
Connection: Keep-Alive
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Fri, 08 Nov 2013 09:32:18 GMT
Server: Apache
Last-Modified: Fri, 08 Nov 2013 08:26:03 GMT
ETag: "52a0012-179fc-4eaa622086ff2"
Accept-Ranges: bytes
Content-Length: 96764
Cache-Control: max-age=2592000
Expires: Sun, 08 Dec 2013 09:32:18 GMT
Vary: Accept-Encoding,User-Agent
Keep-Alive: timeout=120, max=9999
Connection: Keep-Alive
Content-Type: text/plain; charset=UTF-8
---response end---
b) A client that asks for compression (Accept-Encoding):
% wget --debug --header='Accept-Encoding: gzip' https://myserver.dom.ain/userdir/aa2
---request begin---
GET /files/users/cciri01/aa2 HTTP/1.1
User-Agent: Wget/1.13.4 (linux-gnu)
Accept: /
Host: chest.iri.upc.edu
Connection: Keep-Alive
Accept-Encoding: gzip
---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Date: Fri, 08 Nov 2013 09:39:20 GMT
Server: Apache
Last-Modified: Fri, 08 Nov 2013 08:26:03 GMT
ETag: "52a0012-179fc-4eaa622086ff2"
Accept-Ranges: bytes
Cache-Control: max-age=2592000
Expires: Sun, 08 Dec 2013 09:39:20 GMT
Vary: Accept-Encoding,User-Agent
Content-Encoding: gzip
Content-Length: 11539
Keep-Alive: timeout=120, max=9999
Connection: Keep-Alive
Content-Type: text/plain; charset=UTF-8
---response end---
As you can see the server transfers the same original content in two differnt encodings, the only headers that change are the ones related with the request itself: Date, Content-Length, Content-Encoding (of course!), and some others (Vary, Expires,...). The headers related to the original file content remains the same: Last-Modified, ETag, Content-Type.
In conclusion: Accept-Encoding/Content-Encoding works well and CORRECLY for davfs2 with the patch I submitted.
HtH.
Cheers,
Evili
|