Tuomas Lukinmaa <tumu at iki.fi> writes:
> It seems that FProxy fills in the Expires and Last-Modified headers on
> responses with localized dates which is incorrect according to
> HTTP/1.1 specs.
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.3.1 )
Right, I forgot about locales. I applied this patch to the unstable branch:
diff -u -r1.5 HttpServletResponseImpl.java
--- src/freenet/support/servlet/http/HttpServletResponseImpl.java 15 Oct
2002 01:35:44 -0000 1.5
+++ src/freenet/support/servlet/http/HttpServletResponseImpl.java 2 Nov
2002 19:16:55 -0000
@@ -128,7 +128,7 @@
addDateHeader(name, date);
}
- static private SimpleDateFormat dateFormat = new SimpleDateFormat("EEE, dd
MMM yyyy HH:mm:ss 'GMT'");
+ static private SimpleDateFormat dateFormat = new SimpleDateFormat("EEE, dd
MMM yyyy HH:mm:ss 'GMT'", Locale.ENGLISH);
public void addDateHeader(String name, long date) {
headers.put(name, dateFormat.format(new Date(date)));
}
> Also, HTTP/1.1 requires that any compliant server includes Date header
> with all responses (unless the server is clockless).
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18 )
Yeah. But fixing that is pretty low priority for me until you show me
that it breaks something other than a spec (e.g. a real client). We do
include Date in /some/ responses.
> Furthermore, if you look at the response to the GET below, you would
> notice that FProxy is responding with wrong reply code. It should be
> using 304 Not Modified if the content hasn't gone stale.
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.5 ,
> http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3 )
TODO.
In a related vein, DNF and friends should perhaps be 404s.
> It would also be sensible to return ETag header to allow additional
> validity check for stale/fresh content.
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.3 )
I'll think about that.
My current caching target are the web interface images (and static
pages), as these make most sense to cache. For freenet content, I
don't know, we may actualy want to actively prevent caching.
--
Robbe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.ng
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20021102/24da0391/attachment.pgp>