> So we're going to be detecting the corner-case where the user is NOT > using IE and send a 404? Not worth it. We have to A) put in > user-agent detection and B) change a header for 10% of or users. vs. > keeping things the way they are now. Option 2 wins.
If we don't use 404, then it is necessary to ensure that the response is not cached in any circumstances (using all available methods to disable caching on HTTP/1.0 and HTTP/1.1 browsers/proxies, eg. cache-control, Expires, pragma no-cache). It might be a win, but do we want to handle every client like it was the lowest common denominator (eg. IE)? IMHO if we begin doing things that way, we might as well rip out any standard compliance out of FProxy, do everything "the IE way" and ask all users to upgrade to IE in case of any problems. > We don't want a situation where the node is upgraded, some HTML is > changed, and the ETag remains the same! > Last-Modified/Age for this content should be the .jar build time as > well. True. > Yes, but practically speaking, not everyone supports ETag. > Therefore, we should always use all options. Sending a few extra > bytes of header to reduce reloads on various platforms is a net-win > for load. Indeed, if it's feasible to generate such options *accurately*. > If you'll note, when we send a redirect we send a LOT of extra > no-cache headers. Expires in the past, Pragma no-cache, > Cache-Control, etc. Until every system out there works properly, we > need to use them all. You mean, until IE works properly? :) I will bet the hell freezes over first before that happens. And anyway, isn't MS moving away from IE to MSNexplorer which is supposed to have all new codebase? So basically even MS silently acknowledges that supporting IE is a lost cause. Except from such redirect (unnecessary headers removed): +++RESP 41+++ HTTP/1.1 302 Moved Temporarily Pragma: no-cache Location: /KSK at hotdog.ogg Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: post-check=0, pre-check=0 Connection: close Content-type: close Server: Fred 0.5 (build 533) HTTP Servlets +++CLOSE 41+++ +++GET 42+++ GET /KSK at hotdog.ogg HTTP/1.1 Host: 127.0.0.1:8888 Keep-Alive: 300 Connection: keep-alive +++RESP 42+++ HTTP/1.1 403 Forbidden Connection: close Content-type: text/html Server: Fred 0.5 (build 533) HTTP Servlets +++CLOSE 42+++ +++GET 43+++ GET /fproxy_forced_confirm?key=KSK at hotdog.ogg&force=e0e528d1 HTTP/1.1 Host: 127.0.0.1:8888 Keep-Alive: 300 Connection: keep-alive +++RESP 43+++ HTTP/1.1 302 Moved Temporarily Pragma: no-cache Location: /KSK at hotdog.ogg?force=e0e528d1 Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: post-check=0, pre-check=0 Connection: close Content-type: close Server: Fred 0.5 (build 533) HTTP Servlets +++CLOSE 43+++ +++GET 44+++ GET /KSK at hotdog.ogg?force=e0e528d1 HTTP/1.1 Host: 127.0.0.1:8888 Keep-Alive: 300 Connection: keep-alive +++RESP 44+++ HTTP/1.1 302 Moved Temporarily Pragma: no-cache Location: /__INTERNAL__01/-8377344370256885971/ Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: post-check=0, pre-check=0 Connection: close Content-type: close Server: Fred 0.5 (build 533) HTTP Servlets +++CLOSE 44+++ There seems to be few bugs in generating the responses: 1. Content-type: close? 2. Cache-Control: post-check/pre-check? HTTP/1.1 spec doesn't have those listed, so they have to be extensions. Can someone tell which browser/proxy supports them? Maybe it would be more compatible with various clients to add a response written in spec? (3. Already noted in before, every response is missing Date header.) http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 _______________________________________________ devl mailing list devl at freenetproject.org http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
