- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Wed, 18 Jul 2007 01:37:13 +0200
- To: yngve@opera.com
- Cc: ietf-http-wg@w3.org
- Message-Id: <1184715433.5862.18.camel@henriknordstrom.net>
ons 2007-07-18 klockan 01:05 +0200 skrev Yngve Nysaeter Pettersen: > The problems I have been seeing the past few years have appeared to be > caused by intermediate servers or frontends, which may work as > loadbalancers or reverse proxies. The problem with these is that there is > no way to detect them. And additionally, if the protocol is extended by a new header allowing the server to signal it supports pipelining, these intermediary devices is likely to still screw things up just as badly. As I see it is the same as Jamie, the only path out of this is a common HTTP validation test suite, allowing server (and intermediary) authors to verify their implementation. Co-Advisor is one important step on that path. Things like the pipelining problems easily crop up during development, even on a minor revision, and is often just as easily fixed once the developer is aware of the problem. The invalid content-length problem is tricker, as it's root cause is often more application level than server or individual server components.. but it's easy to test for, and should be easy to convince the ones responsible that it's a fault in their implementation.. but i'd also say it should be expected from most servers that they close the connection if they see an server application (or plugin module) generating a response with an incorrect content-length, with an error log entry about the application malfunction. However, I also don't think many servers do this today.. Regards Henrik
Received on Tuesday, 17 July 2007 23:37:21 UTC