On Thu, Dec 19, 2002 at 07:42:42PM +0200, Tuomas Lukinmaa wrote: > 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. Hmmm. > > >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. Hmmmmm. > > 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). Ok. > > +++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 Eek. It wasn't intended to do that :). We force the charset on all text/ content to prevent a few ambiguities that might be exploitable, that's all. Setting the charset for an image is silly, will be tracked down. > 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. No, unfortunately it isn't on freenet. We cannot send data we cannot interpret with a MIME type of text/html or text/css, without direct user intervention to authorize it, because of filtering. > > Is client sent Cache-Control parsed to allow forced reload of content > (like bypass datastore with splitfiles)? No. However we do not send invalid data. > > 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. Ewww. Maybe with the much heralded server-side javascript implementation :). > > >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. >
-- Matthew Toseland toad at amphibian.dyndns.org amphibian at users.sourceforge.net Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021219/2c6e06e0/attachment.pgp>
