Safari, Rikai.com and HTTP 1.1 compression

By Oli
At 1:49 PM · Sunday, 26 October · 2003
To Japan · The ‘Net

I can’t access Rikai.com using Safari 1.0. Rikai is an invaluable service allowing you to view any Japanese website with dictionary popups for each word. If you can’t remember a word, a simple mouse-over will show the dictionary entry for it. The creator, Todd David Rudick, says that he uses HTTP 1.1 compression, and users have to use a browser that supports this. I can see the page fine in Firebird 0.7, and when I save this page locally from Firebird I can open the file in Safari. However Safari just downloads the page as a .pl file when I try to view it on the ‘net. I can view other .pl pages (for example Bungie.net)

This makes me wonder if Safari supports HTTP 1.1, specifically content compression. I can’t seem to find any information:

Apple’s Website
While there’s an excellent listing of CSS compatibility, I can’t see any mention of what specific standards Safari supports. The main Safari page says Safari renders Web pages properly according to the latest Internet standards , and doesn’t mention HTTP at all (or what versions of other standards are supported). A search for “sarfari http” doesn’t give any good hits.
Google
While I came across the DHTML Kitchen’s Problems with Apple’s Safari Browser, it seems to indicate that HTTP 1.1 wasn’t supported but now is (no information on which build this occurred in). Likewise Mark Pilgrim states in Bandwidth-saving tip of the day that all modern browsers support [gzip compression] (which I guess to mean HTTP 1.1 compression).

I’ve been in touch with Todd, who said he’s received email from other Safari users also unable to access Rikai.com. I’d love to hear officially whether HTTP 1.1 compression is supported before I bug him further about it. Any thoughts? It would be great if a support chart similar to the CSS one for other supported standards could be compiled sometime, by the way ;-)

PS if Dave or one of the Safari team checks this trackback out — thanks for the great browser!

Discussion...

Comments (4) · TrackBacks (0)  to  http://www.boblet.net/cgi-bin/mttb-external.cgi/29
1. Comment by hyatt  · 26 Oct, 2003 · 2:24 PM

Safari supports some types of compression (e.g., gzip) but not all of them. It indicates clearly what types of compression it supports, so that information is available to the server.

We have found that some servers were misconfigured to assume that all types of compression would work even when the browser clearly indicates otherwise. This could be a server error.

2. Comment by oli  · 26 Oct, 2003 · 6:10 PM

Thanks for the rapid response Dave! I’ll follow it up with Todd of rikai.com. I think he’s using content-encoding:·deflate based on the headers Todd’s server sends:

HTTP/1.1 200 OK
Date: Sun, 26 Oct 2003 08:44:52 GMT
Server: Apache/1.3.26 (Unix) mod_perl/1.27
Set-Cookie: lastLang=En; path=/; expires=Sat, 24-Jan-2004 08:44:53 GMT
Expires: Sun, 26 Oct 2003 08:44:54 GMT
content-encoding: deflate
vary: *
last-modified: Sun, 26 Oct 2003 08:44:43 GMT
cache-control: private
Content-Type: text/html; charset=euc-jp
X-Cache: MISS from rikai.com
Connection: close

However I found something interesting when using the only HTTP request viewer I could find. When I access it with Safari it doesn’t seem to display any Accept-Encoding information:

GET /some/url.html HTTP/1.1 Host: www.delorie.com:81 Connection: keep-alive Referer: http://www.delorie.com/web/ User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5 Accept: */* Accept-Language: en-us, ja;q=0.90, ja-jp;q=0.93, en;q=0.97, fr-fr;q=0.86, fr;q=0.83, de-de;q=0.79, de;q=0.76, es-es;q=0.72, es;q=0.69, it-it;q=0.66, it;q=0.62, nl-nl;q=0.59, nl;q=0.55, pt-pt;q=0.52, pt;q=0.48, sv-se;q=0.45, sv;q=0.41, no-no;q=0.38, no;q=0.34, da-dk;q=0.31, da;q=0.28, fi-fi;q=0.24, fi;q=0.21, zh-cn;q=0.17, zh-tw;q=0.14, zh;q=0.10, ko-kr;q=0.07, ko;q=0.03

However when I access it with Firebird 0.7 I get a quite different set of information:

GET /some/url.html HTTP/1.1
Host: www.delorie.com:81
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6
Accept: text/xml,application/xml, application/xhtml+xml, text/html;q=0.9,text/plain;q=0.8, video/x-mng,image/png, image/jpeg,image/gif; q=0.2,*/*;q=0.1
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate,compress;q=0.9
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.delorie.com/web/

Is it possible that Safari 1.0 isn’t sending the Accept-Encoding information it should be?

I’m buying a new G5 tomorrow, so if I don’t get a response from you here I’ll test it on Safari 1.1 before bugging you again ;-)

3. Comment by Kirk Samuelson  · 29 Oct, 2003 · 1:28 AM

I believe you are correct that Safari (1.0) doesn’t send an Accept-Encoding header in the request. Whether rikai.com should make the assumption that deflate is OK without that header… I have no opinion. :-)

For industrial strength tcp data viewing get tcpflow or the package installer of the same.

Also, Interarchy, the S/FTP client, has a traffic watcher based on tcpflow.

4. Comment by oli  · 9 Nov, 2003 · 10:58 AM

My computer buying is temporarily on hold, but to view a server’s HTTP header packet use Rex Swain’s HTTP Viewer.