Chromium

[Empty comment from Monorail migration]

Sorry I didn't get back to you sooner, overlooked the bug.  Are you still having this problem?  I can't reproduce it on the latest stable version (16.0.912.75).

I can reproduce this error by filling out this form and clicking submit:

https://quiltvertiser.danemcoweb.com/accounts/register/publisher/

The browser sits for about 60 seconds and then comes back with:

No data received
Unable to load the webpage because the server sent no data.
Here are some suggestions:
Reload this webpage later.
Error 324 (net::ERR_EMPTY_RESPONSE): The server closed the connection without sending any data.


However, the page submit and comes right back without any trouble when using Firefox 9.0 and Internet Explorer.

This is my version of Google Chrome:

Google Chrome   16.0.912.75 (Official Build 116452)
OS      Linux
WebKit  535.7 (@103989)
JavaScript      V8 3.6.6.15
Flash   11.1 r102
User Agent      Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.7 (KHTML, like Gecko) Chrome/16.0.912.75 Safari/535.7
Command Line     /opt/google/chrome/google-chrome --flag-switches-begin --enable-print-preview --flag-switches-end
Executable Path /opt/google/chrome/google-chrome
Profile Path    /home/dpurcell/.config/google-chrome/Default


I can reproduce the problem in the Windows version of Google Chrome 16.

danielpurcell:  That problem is almost certainly caused by the server not supporting the request headers and post data being split across different responses in HTTPS requests.  There'll be a workaround for that in M17.

The issue reported in this bug report isn't a POST, so it's presumably a different problem.

mmenke: Thanks for the quick reply. I see -- so the issue here is that my server (quiltvertiser.danemcoweb.com) doesn't accept POST data split across responses in HTTPS requests? Why would it work without any trouble in Firefox but break in Chrome? Does Chrome send the requests differently?

FireFox and IE have the workaround we just added.  I believe the original problem was caused when we added support for chunk-encoded/streaming input for POST bodies, which resulted in separating out the code to send the header and the body, since we now might not always have the body when sending the headers.

I've tested the page on Chrome 18 (Don't have 17 handy), and it seems to work fine.  I was also able to reproduce the issue in Chrome 16, so presumably not due to differences in our internet connection/network configurations.

I'm not sure about the exact timeline for Chrome 17's release, but think it'll be sometime in the next couple weeks.

Thank you very much.  Are you aware of anything I can do on the server-side to solve this problem at this time?

You could try and fix the server's code to parse HTTPS requests.  This could be a significant undertaking or a trivial fix, depending on the software it's running.

Parse the split HTTPS requests, rather.

OK, thanks. I'm using lighttpd and apache (both are experiencing the same behavior), so I'll need to dive into it to see what can be done. Thanks for your insight.

danielpurcell:  The issue used to track that bug is https://crbug.com/chromium/107966, though not sure there's any more info there that will be of use to you.

Back to the issue at hand:  ltreugene, now that I look at what happens when loading that site, it's actually also the POST issue danielpurcell is encountering, so I'm going to go ahead and merge this bug.

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.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Monorail components: Internals>Network]

[Empty comment from Monorail migration]

[Monorail components: -Internals>Network>HTTP]

This issue was migrated from crbug.com/chromium/108714?no_tracker_redirect=1

[Multiple monorail components: Internals, Internals>Network]
[Monorail mergedinto: crbug.com/chromium/107966]
[Monorail components added to Component Tags custom field.]