MantisBT - NetSurf
View Issue Details
0002252NetSurf[All Projects] Generalpublic2015-01-10 17:462016-11-22 21:54
ReporterChris Young 
Assigned ToChris Young 
PlatformAmigaOSAmigaOSOS Version4.1
Product Version3.3 
Target VersionFixed in Version3.6 
Fixed in CI build #3751
Reported in CI build #2514
URL of problem page
Summary0002252: Server returned nothing when posting >~550bytes
DescriptionI get the following error when posting about more than 550 bytes in the Digital Spy forums:
Server returned nothing (no headers, no data)

This appears after an apparent timeout waiting for data to be received back.
Steps To ReproduceVisit (you will need an account)
Start or reply to an existing thread with more than 550 characters
Click "preview post" or "go advanced" (this causes the same error as submitting, but without actually starting a thread)
Additional InformationThis seems to happen quite consistently, although when I was trying to reproduce to get a log file with the curl debug I couldn't reproduce it (it has happened again since). If I can get a log I'll add it.
I'm unable to reproduce on the GTK or Windows versions of NetSurf at this time, or on any other website. It seems quite isolated but this was definitely working last year (November?). I've tried updating to libcurl 7.40 but it hasn't made any difference.
TagsNo tags attached.
Attached Filesgz ns.log.gz (77,311) 2015-01-13 19:18
7z wireshark.7z (15,554) 2015-04-26 14:15

Chris Young   
2015-01-13 19:21   
Log attached - Contains a couple of successes and then a failure (as I added more and more text to produce the issue).

The key failure part is this:
* Connection died, retrying a fresh connect
* Closing connection 0
* Issue another request to this URL: ''
* Found bundle for host 0x570519f8
* Connection 10 seems to be dead!
* Closing connection 10
* Hostname was NOT found in DNS cache
* Trying
* Connected to ( port 80 (#21)
> POST /newthread.php?do=postthread&f=108 HTTP/1.1
User-Agent: NetSurf/3.3 (AmigaOS)
Accept: */*
Accept-Encoding: gzip
Cookie: bblastvisit=1417044682; bblastactivity=0; bbuserid=xxxx; bbpassword=xxxxxxxxxxxxx; DSid=7329%3A4ae4f30b0cfb624dca3aaaa097c6ddd0; hearst_id=66379000; bbsessionhash=492ca0a0361c465e1320eed1262516de
Accept-Language: en-GB, en, *;q=0.1
DNT: 1
Content-Length: 906
Content-Type: application/x-www-form-urlencoded

* upload completely sent off: 906 out of 906 bytes
* Empty reply from server
* Connection #21 to host left intact
(204.103683) content/fetchers/curl.c fetch_curl_done 838: done
(204.103876) content/fetchers/curl.c fetch_curl_done 876: Unknown cURL response code 52
(204.103926) content/fetchers/curl.c fetch_curl_stop 703: fetch 0x55a45fd0, url ''
(204.137399) amiga/misc.c ami_misc_req 54: Server returned nothing (no headers, no data)

I suspect "Unknown cURL response code 52" might be the key.
Chris Young   
2015-01-13 19:27   
A quick Google reveals this (old) message:

In that case the server was segfaulting, so it might be the same problem here, in which case we won't be able to do much about it, unless we are sending something weird to the server.
Vincent Sanders   
2015-03-01 16:13   
well the curl error is CURLE_GOT_NOTHING (52) in general our handling of curl error codes is very poor.
Chris Young   
2015-04-26 14:03   
I've had a nose around with Wireshark to try and figure out what is going on. It appears when the "nothing received" error appears, NetSurf has not even attempted to send the request. I've attached the logs for the failure [wireshark_ds.pcapng] and the log for a working request (ie. with much shorter input) [wireshark_ds_working.pcapng]
Chris Young   
2015-04-26 15:14   
Looking at Curl, it appears that it handles posts >1K slightly differently, which would explain why adding extra characters suddenly stops it working. this is the relevant excerpt from curl http.c:

    /* For really small posts we don't use Expect: headers at all, and for
       the somewhat bigger ones we allow the app to disable it. Just make
       sure that the expect100header is always set to the preferred value
       here. */
    ptr = Curl_checkheaders(conn, "Expect:");
    if(ptr) {
      data->state.expect100header =
        Curl_compareheader(ptr, "Expect:", "100-continue");
    else if(postsize > TINY_INITIAL_POST_SIZE || postsize < 0) {
      result = expect100(data, conn, req_buffer);
        return result;
      data->state.expect100header = FALSE;

As this appears to be related to Expect: 100-continue, I tried removing the line in NetSurf which disables that header. I'm now getting an HTTP 100 Continue response from the server, but of course NetSurf doesn't know what to do with it.

I'm thinking the bug might be in libcurl, where with >1K posts the non-Expect:100 behaviour isn't working correctly.
Chris Young   
2016-11-14 19:08   
I have no idea what has changed or when, but this is working now.
Vincent Sanders   
2016-11-22 21:54   
this issue has been closed because it is included in the 3.6 release

Issue History
2015-01-10 17:46Chris YoungNew Issue
2015-01-13 19:18Chris YoungFile Added: ns.log.gz
2015-01-13 19:21Chris YoungNote Added: 0000567
2015-01-13 19:27Chris YoungNote Added: 0000568
2015-01-16 09:05Vincent SandersStatusnew => acknowledged
2015-01-16 09:05Vincent SandersDescription Updatedbug_revision_view_page.php?rev_id=1387#r1387
2015-01-16 09:05Vincent SandersSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=1389#r1389
2015-01-16 09:05Vincent SandersAdditional Information Updatedbug_revision_view_page.php?rev_id=1391#r1391
2015-03-01 16:13Vincent SandersNote Added: 0000619
2015-04-26 14:00Chris YoungFile Added: wireshark_ds_working.pcapng
2015-04-26 14:01Chris YoungFile Added: wireshark_ds.pcapng
2015-04-26 14:03Chris YoungNote Added: 0000837
2015-04-26 14:14Chris YoungFile Deleted: wireshark_ds_working.pcapng
2015-04-26 14:15Chris YoungFile Deleted: wireshark_ds.pcapng
2015-04-26 14:15Chris YoungFile Added: wireshark.7z
2015-04-26 15:14Chris YoungNote Added: 0000839
2016-11-14 19:08Chris YoungFixed in CI build # => 3751
2016-11-14 19:08Chris YoungNote Added: 0001416
2016-11-14 19:08Chris YoungStatusacknowledged => resolved
2016-11-14 19:08Chris YoungFixed in Version => 3.6
2016-11-14 19:08Chris YoungResolutionopen => fixed
2016-11-14 19:08Chris YoungAssigned To => Chris Young
2016-11-22 21:54Vincent SandersNote Added: 0001422
2016-11-22 21:54Vincent SandersStatusresolved => closed