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>

Reply via email to