> 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: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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?[EMAIL PROTECTED]&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: [EMAIL PROTECTED]?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 [EMAIL PROTECTED]?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
[EMAIL PROTECTED]
http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to