[erlang-questions] Re: [erlang-questions 29] Re: fun with the new erlang.org!

[Steve Vinoski]

On Thu, Mar 31, 2011 at 3:25 AM, Raimo Niskanen
<raimo+erlang-questions@REDACTED> wrote:
> On Thu, Mar 31, 2011 at 12:07:55AM +0200, Antoine Koener wrote:
>>
>> On Mar 30, 2011, at 13:50 , Steve Vinoski wrote:
>>
>> >On Wed, Mar 30, 2011 at 7:41 AM, Raimo Niskanen
>> ><raimo+erlang-questions@REDACTED> wrote:
>> >>On Sat, Mar 26, 2011 at 05:03:56PM +0100, Koener Antoine wrote:
>> >>>Cacheability ?
>> >>>
>> >>>I can reload the page multiples times and still download images.
>> >>>
>> >>>It seems also that images don't have any 'cache' attributes.
>> >>>(I don't recommended using ETags unless you're absolutely sure that
>> >>>ETags will be always the
>> >>>same on multiple web servers. i.e. some webservers use inode
>> >>>information to compute the ETag
>> >>>which is different on different servers...thought I don't know how
>> >>>erlang-web compute it)
>> >>
>> >>Please inform a newbie, I just checked HTML4.01 and did not
>> >>find any "cache" attribute.
>> >
>> >He's referring to cache control headers such as Expires, ETag, and
>> >Cache-Control. These aren't part of HTML but rather are typically
>> >configured for the web server itself. See section 13 of the HTTP 1.1
>> >spec:
>> >
>> >http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13
>>
>> Exactly Steve,
>>
>> Raimo,
>>
>> Here's a simple method to determine how 'caching' is handled by the
>> webserver:
>> http://www.ircache.net/cgi-bin/cacheability.py?query=http%3A%2F%2Fwww.erlang.org%2Fimages%2Fsearch_bar.jpg&descend=on
>>
>> It seems that inets isn't really ideal for serving real web content,
>> because [extracted from the web page]:
>> Last-Modified  70 weeks 5 days ago  (Fri, 20 Nov 2009 11:37:29 GMT)
>> validation returned same object
>>
>> If-Modified-Since are HTTP headers means:
>>  me (web browser talking) please web server give me only content that
>> has changed since this "date", because I don't need to
>> retrieve the same content since I already have it...
>>
>> Unfortunately inets sends the same content every time a HTTP GET is
>> done, regardless of HTTP headers.
>>
>> I hope that this explanation will clarify a bit more.
>
> It seems so, thank you very much. Now I have something to dig into.
> Part of the reason why we run Inets on the site is to find out what
> problems it has. We supposedly can change web server to Yaws or even
> maybe Mochiweb (I do not remember), but would preferably take the
> opportunity to fix Inets. I am not on the Inets team so I will take
> this to them...

Also a bit unusual is the website's failure to respond to HEAD
requests, as this verbose output from curl shows:

$ curl -Iv http://www.erlang.org/
* About to connect() to www.erlang.org port 80 (#0)
*   Trying 192.121.151.107... connected
* Connected to www.erlang.org (192.121.151.107) port 80 (#0)
> HEAD / HTTP/1.1
> User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8l zlib/1.2.3
> Host: www.erlang.org
> Accept: */*
>
* Empty reply from server
* Connection #0 to host www.erlang.org left intact
curl: (52) Empty reply from server
* Closing connection #0

A website technically doesn't need to respond to HEAD requests but for
purposes of cache coherency it's common for caches to use both
conditional GETs (which is why supporting ETag and cache control
headers is important) and HEAD requests for checking for updates on
origin servers.

--steve