Matthew Toseland wrote: > Actually, it does now. Have you tried lately?
Good work. > 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 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. > 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. 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. 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 devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
