Matthew Toseland wrote:
Actually, it does now. Have you tried lately?
Good work.
Those cache directives are redundant on redirects as only permanent redirects are cached by default. All other 3xx's require explicit caching headers to be cached.Firstly, the don't-cache-redirects code, and the infolets: GET / HTTP/1.0 HTTP/1.1 302 Moved Temporarily Date: Thu, 19 Dec 2002 11:42:39 GMT Pragma: no-cache Location: /servlet/nodeinfo/ Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: post-check=0, pre-check=0 Connection: close Content-length: 191 Content-type: text/html;charset=ISO-8859-1 Server: Fred 0.5 (build 539) HTTP Servlets
It's fine, only thing I would like to see fixed is keep-alive connections when accessing infolet content, at the moment they're closed after one response.Secondly, the actual infolets: - OK, we don't set enough caching headers on the infolets. Go implement it if you care, otherwise it's in the queue.
With HTTP/1.0 clients, Connection header (and any header names parsed from Connection attributes, fe. Connection: keep-alive and possible keep-alive header) from client should ignored to prevent broken keep-alive connections happening over old proxies which might forward the header (fe. 1.1 client->1.0 proxy->fproxy).
+++GET 2488+++
GET /servlet/images/aqua/bar_right.gif HTTP/1.1
Host: 127.0.0.1:8888
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2) Gecko/20021126
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Accept: video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Referer: http://127.0.0.1:8888/servlet/images/aqua/bar_right.gif
If-Modified-Since: Thu, 19 Dec 2002 18:20:41 GMT
Cache-Control: max-age=0
Connection: keep-alive
+++RESP 2488+++
HTTP/1.1 200 OK
Date: Thu, 19 Dec 2002 18:21:02 GMT
Expires: Fri, 20 Dec 2002 18:21:02 GMT
Last-Modified: Thu, 19 Dec 2002 18:20:41 GMT
Connection: close
Content-type: image/gif;charset=ISO-8859-1
Server: Fred 0.5 (build 539) HTTP Servlets
Another issue you can see above is the Content-type charset attribute, gif's naturally are raw binary data. :) I don't know how the charset is determined but if it can't be done accurately (or if we're dealing with old client), it should not be included in a response. It's better to leave the charset parsing to client than to override it with wrong one.
Is client sent Cache-Control parsed to allow forced reload of content (like bypass datastore with splitfiles)?
There might be idea for future development to allow content authors specify copies of their content with different data types in metadata and use the clients' Accept and Accept-Charset (and other content negotiation) headers to return best-suited content to the client automatically.
I have asked for HTTP/1.0 each time just to shorten the requests - I don't think it changes the returned headers.
No it doesn't, old clients just ignore any new headers. _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
