- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 8 Oct 2010 13:41:50 -0700
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: "Roy T. Fielding" <fielding@gbiv.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Great. At that frequency of occurrence, we should just fail the request with a fatal error and close the socket. I don't see any reason to partially render the page. Adam On Fri, Oct 8, 2010 at 11:55 AM, William Chan (陈智昌) <willchan@chromium.org> wrote: > FWIW, on Windows Chrome 7.0.536.2 (a recent dev channel release), .0009% of > main frames (where an error would result in a user-visible Chrome network > error page, which we don't show for subresources) have responses with > multiple content-lengths. > > On Tue, Sep 21, 2010 at 12:01 AM, William Chan (陈智昌) <willchan@chromium.org> > wrote: >> >> On Mon, Sep 20, 2010 at 11:44 PM, Adam Barth <w3c@adambarth.com> wrote: >>> >>> On Mon, Sep 20, 2010 at 10:28 PM, William Chan (陈智昌) >>> <willchan@chromium.org> wrote: >>> > From the brief discussion amongst the Chrome network developers, we >>> > plan to >>> > discard the response and display an error. >>> >>> What sort of error message are you planing to display in the case that >>> Mark asked about (a CSS stylesheet with multiple Content-Length >>> headers)? >>> >>> Adam >> >> I missed that comment. That's an interesting point. Unless bug reports / >> user metrics indicate this merits special handling, or we have confidence >> this is an attack rather than a buggy server, I'd have no current plans to >> treat it differently from any other network error, which gets logged and >> results in a resource load failure for WebKit. >
Received on Friday, 8 October 2010 20:42:56 UTC