New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 138 link

Starred by 20 users

Issue metadata

Status: WontFix
Owner:
Email to this user bounced
Closed: Sep 2008
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.


Show other hotlists

Hotlists containing this issue:
Hotlist-1


Sign in to add a comment

Error 320 (net::ERR_INVALID_RESPONSE) on HTTP header field continuation (rgs.tamu.edu and ogs.tamu.edu)

Reported by voss.mat...@gmail.com, Sep 2 2008

Issue description

Product Version      : 0.2.149.27
URLs (if applicable) : rgs.tamu.edu
                       ogs.tamu.edu
 
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 3: OK
    Firefox 3: OK
         IE 7: OK

What steps will reproduce the problem?
1. Navigate to urls listed above
2.
3.

What is the expected result?
The page should render like what is seen in other browsers

What happens instead?
Page does not render at all  but you receive error message: Error 320
(net::ERR_INVALID_RESPONSE): Unknown error.


* Sites are Zope 2.9.8 / Plone 2.5.5 fronted by a squid proxy server.

Headers from Firefox3 LiveHeaders Plugin

http://rgs.tamu.edu/

GET / HTTP/1.1
Host: rgs.tamu.edu
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1)
Gecko/2008070208 Firefox/3.0.1 FirePHP/0.1.1.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie:
__utma=194481448.628806174884237300.1218575151.1218575151.1218575151.1;
__utmz=194481448.1218575151.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)
If-None-Match: ||SkinVPR|en-us;en;q=0.5|1|41692|False|||||338997
Cache-Control: max-age=0

HTTP/1.x 304 Not Modified
Server: Zope/(Zope 2.9.8-final, python 2.4.5, linux2) ZServer/1.1 Plone/2.5.5
Date: Tue, 02 Sep 2008 21:21:16 GMT
Expires: Sat, 05 Sep 1998 21:21:16 GMT
Vary: Accept-Encoding, Accept-Language
Etag: ||SkinVPR|en-us;en;q=0.5|1|41692|False|||||338997
X-Caching-Rule-Id: plone-containers
Cache-Control: max-age=0, s-maxage=0, private, must-revalidate
X-Header-Set-Id: cache-in-memory
X-Cache: MISS from squid0.vpr.int
X-Cache-Lookup: MISS from squid0.vpr.int:80
Via: 1.0 squid0.vpr.int:80 (squid/2.6.STABLE14)
Connection: keep-alive


 
incorrect-rendering-chrome.jpg
23.8 KB View Download
correct-rendering-firefox3.jpg
119 KB View Download
Status: Untriaged
Summary: Error 320 (net::ERR_INVALID_RESPONSE) on rgs.tamu.edu and ogs.tamu.edu
Thanks for the report.

I confirmed that those URLs don't work on the current HTTP stack.  They do, however, 
work fine using the new HTTP stack.

Comment 2 by darin@chromium.org, Sep 3 2008

-> me, so that i can close this once the new http stack is enabled.

Comment 3 by wtc@chromium.org, Sep 3 2008

Chrome fails with the net::ERR_INVALID_RESPONSE error when the
underlying WinHTTP library fails with the ERROR_WINHTTP_INVALID_SERVER_RESPONSE
error.  Here are the headers of a response from http://ogs.tamu.edu/:

   0: 48 54 54 50  2f 31 2e 30  20 32 30 30  20 4f 4b 0d  | HTTP/1.0 200 OK.
  10: 0a 53 65 72  76 65 72 3a  20 5a 6f 70  65 2f 28 5a  | .Server: Zope/(Z
  20: 6f 70 65 20  32 2e 39 2e  38 2d 66 69  6e 61 6c 2c  | ope 2.9.8-final,
  30: 20 70 79 74  68 6f 6e 20  32 2e 34 2e  35 2c 20 6c  |  python 2.4.5, l
  40: 69 6e 75 78  32 29 20 5a  53 65 72 76  65 72 2f 31  | inux2) ZServer/1
  50: 2e 31 20 50  6c 6f 6e 65  2f 32 2e 35  2e 35 0d 0a  | .1 Plone/2.5.5..
  60: 44 61 74 65  3a 20 57 65  64 2c 20 30  33 20 53 65  | Date: Wed, 03 Se
  70: 70 20 32 30  30 38 20 31  39 3a 31 31  3a 30 38 20  | p 2008 19:11:08
  80: 47 4d 54 0d  0a 58 2d 50  61 67 65 63  61 63 68 65  | GMT..X-Pagecache
  90: 3a 20 4d 49  53 53 0d 0a  43 6f 6e 74  65 6e 74 2d  | : MISS..Content-
  a0: 4c 65 6e 67  74 68 3a 20  37 31 33 38  0d 0a 43 6f  | Length: 7138..Co
  b0: 6e 74 65 6e  74 2d 4c 61  6e 67 75 61  67 65 3a 20  | ntent-Language:
  c0: 65 6e 0d 0a  43 6f 6e 74  65 6e 74 2d  45 6e 63 6f  | en..Content-Enco
  d0: 64 69 6e 67  3a 20 67 7a  69 70 0d 0a  45 78 70 69  | ding: gzip..Expi
  e0: 72 65 73 3a  20 53 75 6e  2c 20 30 36  20 53 65 70  | res: Sun, 06 Sep
  f0: 20 31 39 39  38 20 31 39  3a 31 31 3a  30 33 20 47  |  1998 19:11:03 G
 100: 4d 54 0d 0a  56 61 72 79  3a 20 41 63  63 65 70 74  | MT..Vary: Accept
 110: 2d 45 6e 63  6f 64 69 6e  67 2c 20 41  63 63 65 70  | -Encoding, Accep
 120: 74 2d 4c 61  6e 67 75 61  67 65 2c 0d  0a 09 41 63  | t-Language,...Ac
 130: 63 65 70 74  2d 45 6e 63  6f 64 69 6e  67 0d 0a 45  | cept-Encoding..E
 140: 54 61 67 3a  20 7c 7c 53  6b 69 6e 4f  47 53 7c 65  | Tag: ||SkinOGS|e
 150: 6e 2d 55 53  3b 65 6e 7c  31 7c 31 38  38 31 32 35  | n-US;en|1|188125
 160: 7c 46 61 6c  73 65 7c 7c  7c 7c 7c 33  33 39 30 31  | |False|||||33901
 170: 39 0d 0a 58  2d 43 61 63  68 69 6e 67  2d 52 75 6c  | 9..X-Caching-Rul
 180: 65 2d 49 64  3a 20 70 6c  6f 6e 65 2d  63 6f 6e 74  | e-Id: plone-cont
 190: 61 69 6e 65  72 73 0d 0a  43 61 63 68  65 2d 43 6f  | ainers..Cache-Co
 1a0: 6e 74 72 6f  6c 3a 20 6d  61 78 2d 61  67 65 3d 30  | ntrol: max-age=0
 1b0: 2c 20 73 2d  6d 61 78 61  67 65 3d 30  2c 20 70 72  | , s-maxage=0, pr
 1c0: 69 76 61 74  65 2c 20 6d  75 73 74 2d  72 65 76 61  | ivate, must-reva
 1d0: 6c 69 64 61  74 65 0d 0a  43 6f 6e 74  65 6e 74 2d  | lidate..Content-
 1e0: 54 79 70 65  3a 20 74 65  78 74 2f 68  74 6d 6c 3b  | Type: text/html;
 1f0: 63 68 61 72  73 65 74 3d  75 74 66 2d  38 0d 0a 58  | charset=utf-8..X
 200: 2d 48 65 61  64 65 72 2d  53 65 74 2d  49 64 3a 20  | -Header-Set-Id:
 210: 63 61 63 68  65 2d 69 6e  2d 6d 65 6d  6f 72 79 0d  | cache-in-memory.
 220: 0a 58 2d 43  61 63 68 65  3a 20 4d 49  53 53 20 66  | .X-Cache: MISS f
 230: 72 6f 6d 20  73 71 75 69  64 30 2e 76  70 72 2e 69  | rom squid0.vpr.i
 240: 6e 74 0d 0a  58 2d 43 61  63 68 65 2d  4c 6f 6f 6b  | nt..X-Cache-Look
 250: 75 70 3a 20  4d 49 53 53  20 66 72 6f  6d 20 73 71  | up: MISS from sq
 260: 75 69 64 30  2e 76 70 72  2e 69 6e 74  3a 38 30 0d  | uid0.vpr.int:80.
 270: 0a 56 69 61  3a 20 31 2e  30 20 73 71  75 69 64 30  | .Via: 1.0 squid0
 280: 2e 76 70 72  2e 69 6e 74  3a 38 30 20  28 73 71 75  | .vpr.int:80 (squ
 290: 69 64 2f 32  2e 36 2e 53  54 41 42 4c  45 31 34 29  | id/2.6.STABLE14)
 2a0: 0d 0a 43 6f  6e 6e 65 63  74 69 6f 6e  3a 20 6b 65  | ..Connection: ke
 2b0: 65 70 2d 61  6c 69 76 65  0d 0a 0d 0a  1f 8b 08 00  | ep-alive........

The Fiddler 2 tool complained about "Junk in response header #9.
Data: Accept-Encoding".  The Vary header is:

    Vary: Accept-Encoding, Accept-Language\r\n\tAccept-Encoding

Note the use of header continuation.  Before I look into this further,
I can speculate why WinHTTP doesn't like this header:
- Perhaps WinHTTP doesn't support header continuation lines.
- Perhaps WinHTTP disallows repeated values (Accept-Encoding) in the
  Vary header.
- Perhaps WinHTTP wants a comma after Accept-Language in the Vary header.

Comment 4 by wtc@chromium.org, Sep 3 2008

I have confirmed that it is the header continuation line that WinHTTP doesn't
like.  (I missed the comma after Accept-Language in the Vary header.  It is
there in the response.)  If I replace \r\n\t with a space character, WinHTTP
accepts the response.

Comment 5 by wtc@chromium.org, Sep 4 2008

I submitted a bug report to Microsoft:
http://connect.microsoft.com/WNDP/feedback/ViewFeedback.aspx?FeedbackID=365976

We will fix this bug in Chrome by finishing and switching to our new HTTP stack.

The new HTTP stack needs to support header field continuation.

By the way, Fiddler v2.1.6.2 doesn't support header field continuation either,
which is why it complained about "Junk in response header".
I've starred the issue but I wanted to confirm that our internal Intranet, which uses
almost the same setup as mentioned by voss, experiences the same error when I start
navigating it. Good to hear that the new HTTP stack fixes the issue. I look forward
to an update. Thank you!

Comment 7 by wtc@chromium.org, Sep 4 2008

If you can modify your servers, you can change it to
send the Vary header like this:

  Vary: Accept-Encoding, Accept-Language\r\n

instead of this:

  Vary: Accept-Encoding, Accept-Language,\r\n\tAccept-Encoding\r\n

to work around this bug.  As you can see, the second "Accept-Encoding"
(in the header field continuation line) is redundant.
I have made a change to the Caching product configuration in Plone to change the
headers on both sites and I think it has resolved the problem. I'm not sure what is
appending the extra Accept-Encoding, that is something I'm going to need to discuss
with our Sys Admins.

Thanks for the heads up and for all the effort you put in!

Comment 9 by wtc@chromium.org, Sep 5 2008

Yes, I see that your Vary header is now just

  Vary: Accept-Language

without Accept-Encoding and header field continuation.

Eric Roman is implementing header field continuation support in our new
HTTP stack (http://codereview.chromium.org/458).
might add adobe feeds http://feeds.adobe.com/ to your test suite. same error.
Note sure if this is the same issue but I also get that error (Error 320 
(net::ERR_INVALID_RESPONSE): Unknown error.) when trying to bring up the default 
gateway of a NETGEAR ProSafe VPN Firewall FVS336G (https://192.168.1.251/scgi-
bin/index.htm).

Comment 12 by wtc@chromium.org, Sep 9 2008

Labels: -OS-All -Area-Unknown OS-Windows Area-BrowserBackend
Status: Started
Summary: Error 320 (net::ERR_INVALID_RESPONSE) on HTTP header field continuation (rgs.tamu.edu and ogs.tamu.edu)
net::ERR_INVALID_RESPONSE covers several different problems with a
server's response.  This bug is specifically on the problem with
HTTP header field continuation.

Unless you have verified that the problem you encountered is also
caused by HTTP header field continuation, please file separate bug
reports so that we can investigate them.

Comment 13 by dtfi...@gmail.com, Sep 9 2008

I get this error trying to connect to our Linksys RVS4000 router. Normally, a login 
prompt would be displayed.

header according to wget:
HTTP/1.0 401 Unauthorized
Server:
Date: Tue, 09 Sep 2008 17:28:26 GMT
WWW-Authenticate: Basic realm="Linksys RVS4000"
Content-Type: text/html
Connection: close

Maybe the empty "Server: " is messing it up.

Comment 14 by wtc@chromium.org, Sep 9 2008

dtfinch, could you open a new bug report for the Linksys RVS4000 router
problem?  I will investigate it.
Wan-teh: see  issue #1863  and  issue#297 

Comment 16 by wtc@chromium.org, Sep 11 2008

Status: WontFix
I'm going to close this bug with the WontFix status.  As long as
we're using WinHTTP, we can't fix this bug.  Eric Roman just added
HTTP header field continuation support to the new HTTP stack in
r1818 on 2008-09-05.  When we switch to the new HTTP stack, this
bug will be fixed.

Comment 17 by Deleted ...@, Sep 12 2008

me too have same problem in many sites !!

Comment 18 by wtc@chromium.org, Sep 12 2008

While investigating  issue 2060 , I gained more insight into this
issue.  Because WinHTTP doesn't support header field continuation,
a continuation line is just a junk line to WinHTTP.  By experiments,
I found that WinHTTP requires a header contain a colon (:).  This
is how a header is defined in RFC 2616 Section 4.2:

message-header = field-name ":" [ field-value ]

WinHTTP doesn't allow these

"Server:\r\n"
" TestServer\r\n"

or

"p3pP=\"NON CUR OTPi OUR NOR UNI\"\r\n"

But it allows these, which contain colons in the continuation
line and junk line:

"Server:\r\n"
" TestServer:\r\n"

or

"p3pP:\"NON CUR OTPi OUR NOR UNI\"\r\n"

The contiuation line " TestServer:\r\n" is passed to us
as a separate header, with the leading space removed:

"TestServer:\r\n"

As another example, this is bad:

"  \t \tCrazy Stuff Ugh!\r\n"

but this is good:

"  \t \tCrazy Stuff Ugh!:  \r\n"

and is passed to us as

"Crazy Stuff Ugh!:\r\n"

Same problem accessing a local Motorola Surfboard cablemodem at http://192.168.100.1/
Works fine in Firefox, IE.


Comment 20 by Deleted ...@, Oct 3 2008

I dunno if it's the same problem but I can't access facebook.com nor php.net with 
Chrome, both landing me at a 320 error. I'm updated to the Chrome dev channel and it 
has not really changed things. Right after the update I got php.net to load once but 
facebook would not. Then I cleared my cookies and got PHP.net to load but facebook 
would not. Pressing refresh on either page after it loaded successfully was enough to 
go back to 320 errors. My advice to the chrome developers: Drop WinHTTP and write 
your own stack, or better grab an open source one. On a side note: stop blocking the 
page content sent with 404 errors and other such things. That's just evil.

Comment 21 by Deleted ...@, Oct 13 2008

Same problem here : 
a lot of websites give me the 320 error with Chrome but not with FF or others.

Do I have to send info on my PC config ?

Comment 22 by Deleted ...@, Oct 13 2008

> Do I have to send info on my PC config ?

We believe we have fixed the line continuation problem in the new network stack 
(which is not yet the default).
You can try running chromium with the --new-http flag to test it.

Comment 23 by wtc@chromium.org, Oct 13 2008

sseb25: to investigate "Error 320 (net::ERR_INVALID_RESPONSE)", we don't need
your PC config.  But in general it's good to tell us the Windows version and
service pack level.

What helps us debug this is some test URLs of those websites that give you
the 320 error, so that we can reproduce and look at the error.

Also, error 320 covers a broad class of errors (the HTTP response from the
server is invalid in some way), so it's best to file separate bug reports.

Comment 24 by rudev...@gmail.com, Oct 23 2008

It's was the same error in http://careerrussia.ru/ but we have solved it by 
restarting the server (Apache). It was the same trouble in IE and Firefox.

Comment 25 by Deleted ...@, Oct 31 2008

Windows XP / SP3
correctly works with FF and IE6/7

Comment 26 by Deleted ...@, Jan 15 2009

Is the new HTTP Stack in the latest version of Chrome. Our entire office is receiving
the 320 error on various websites.

Comment 27 by wtc@chromium.org, Jan 15 2009

The current Dev channel build (2.0.156.1 or later) uses the new HTTP stack.
If you'd like to test the Dev channel (which is the least stable of the
three channels), please follow the instructions in
http://dev.chromium.org/getting-involved/dev-channel to download and run
Google Chrome Channel Changer to switch to the Dev channel.  You still need
to switch to the Dev channel even if you were on the Dev channel before,
because we just added a new Beta channel and moved the Dev channel subscribers
to the Beta channel.

Comment 28 by Deleted ...@, May 26 2009

we can not connect our website is http://mail.shubhamgroup.com, another sites are 
open properly. only one our site can not open
and one error come in display "Error 320 (net::ERR_INVALID_RESPONSE): Unknown error".
> we can not connect our website is http://mail.shubhamgroup.com, another sites are 

I can't resolve the hostname for that page, therefore can't repro.

The fix for header line continuations bug was pushed out in the latest update -- please 
check to see which version you are running (it should be something like "2.0.172.28")

Comment 30 by wtc@chromium.org, May 26 2009

BipinKasta: an error page with the message
"Error 320 (net::ERR_INVALID_RESPONSE): Unknown error" is a sign
that you're using an old Chrome 1.0.154.x release.  We just
released Chrome 2 last week, so your Chrome installation should
have been automatically updated by now.  Please let us know if
you can connect to your website http://mail.shubhamgroup.com now.
Type "about:version" in the location bar to get Chrome's version
number.

Comment 31 Deleted

Comment 32 by dhh...@gmail.com, May 26 2009

Actually, it looks like mail.shubhamgroup.com is unresolvable (unknown to the rest of 
the Internet) when tried from may worldwide locations (see also comment 29)

See this worldwide ping test:
   http://www.just-ping.com/index.php?vh=mail.shubhamgroup.com

You may need to check your Internet setup for mail.shubhamgroup.com
Labels: -Area-BrowserBackend Area-Internals
 Issue 9008  has been merged into this issue.
Project Member

Comment 35 by bugdroid1@chromium.org, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 36 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Internals Cr-Internals

Sign in to add a comment