After doing some more tests and being unable to reproduce this using a cors request, I have found that this problem does not occur locally when running the webserver on port 80. So it seems to only occur when doing fetch requests on a non-default port

Here is a small test app to reproduce the issue: https://github.com/steijgeler/fetchtest

The port thing doesn't seem to be the case after all, but unsure how to exactly reproduce this issue. It always occurs in this app. The problem also occurs on Chrome Canary

The log you provided says the response headers didn't arrive.
Could you check if the server sends the response? Could you check with other browsers?

Thanks,

== /tests/1 ==

t= 5019 [st=    3]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=0]
t= 5019 [st=    3]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                          --> GET /tests/1 HTTP/1.1
                              Host: localhost:3000
                              Connection: keep-alive
                              User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.101 Safari/537.36
                              Accept: */*
                              Referer: http://localhost:3000/tests
                              Accept-Encoding: gzip, deflate, sdch
                              Accept-Language: en,nl;q=0.8,en-US;q=0.6
                              If-None-Match: W/"eeb536aa6e9ffaccb68865fb549c681e"
t= 5019 [st=    3]     -HTTP_TRANSACTION_SEND_REQUEST
t= 5019 [st=    3]     +HTTP_TRANSACTION_READ_HEADERS  [dt=17742+]
t= 5019 [st=    3]       +HTTP_STREAM_PARSER_READ_HEADERS  [dt=17742+]
t=22761 [st=17745] 

== /tests/2 ==

t=8112 [st=2]     -HTTP_STREAM_REQUEST
t=8112 [st=2]     +HTTP_TRANSACTION_SEND_REQUEST  [dt=1]
t=8112 [st=2]        HTTP_TRANSACTION_SEND_REQUEST_HEADERS
                     --> GET /tests/2 HTTP/1.1
                         Host: localhost:3000
                         Connection: keep-alive
                         User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.101 Safari/537.36
                         Accept: */*
                         Referer: http://localhost:3000/tests
                         Accept-Encoding: gzip, deflate, sdch
                         Accept-Language: en,nl;q=0.8,en-US;q=0.6
                         Cookie: [2037 bytes were stripped]
                         If-None-Match: W/"eeb536aa6e9ffaccb68865fb549c681e"
t=8113 [st=3]     -HTTP_TRANSACTION_SEND_REQUEST
t=8113 [st=3]     +HTTP_TRANSACTION_READ_HEADERS  [dt=2]
t=8113 [st=3]        HTTP_STREAM_PARSER_READ_HEADERS  [dt=2]
t=8115 [st=5]        HTTP_TRANSACTION_READ_RESPONSE_HEADERS
                     --> HTTP/1.1 304 Not Modified
                         Date: Wed, 14 Sep 2016 09:21:37 GMT
                         Connection: close
                         X-Frame-Options: SAMEORIGIN
                         X-XSS-Protection: 1; mode=block
                         X-Content-Type-Options: nosniff
                         ETag: W/"eeb536aa6e9ffaccb68865fb549c681e"
                         Cache-Control: max-age=0, private, must-revalidate
                         X-Request-Id: e05a082d-6ea2-4f35-ab9a-d20b864d68ea
                         X-Runtime: 0.001602
t=8115 [st=5]     -HTTP_TRANSACTION_READ_HEADERS
t=8115 [st=5]      HTTP_CACHE_WRITE_INFO  [dt=0]
t=8115 [st=5]      URL_REQUEST_DELEGATE  [dt=0]
t=8115 [st=5]   -URL_REQUEST_START_JOB
t=8115 [st=5]    URL_REQUEST_DELEGATE  [dt=0]
t=8115 [st=5]    HTTP_CACHE_READ_DATA  [dt=0]
t=8115 [st=5]    URL_REQUEST_JOB_BYTES_READ
                 --> byte_count = 23
t=8115 [st=5]    HTTP_CACHE_READ_DATA  [dt=0]
t=8116 [st=6] -REQUEST_ALIVE

The server doesn't receive the request, so no response is sent.

I've tried this in Canary and Firefox. I occurs in Canary as well, but it works flawlessly in Firefox. I can't test in Safari, since it doesn't support native fetch.

We've tried at a colleague's Mac as well, and at first we couldn't reproduce this. He was running webbrick (different web server). This problem only occurs when the server is running unicorn. I've also tried passenger and puma, those work fine too.

So this issue happens with unicorn webserver, but only from Chrome. Firefox works fine. Unsure if this is a Chrome issue or a Unicorn issue now.

Ah, sorry, I misunderstood. Then the problem is that Chrome thinks that it sent a request but the request doesn't arrive at the server.

chrome-network people, do you have a good idea?

According to the net log, the client does send the request but never gets the response. We don't know whether the server receives the request. Since it works with other servers but doesn't work only with "unicorn", the request probably reaches the server. Could you try wireshark/tcpdump to check whether the request and the response are actually sent by the client and the server? If it works with another browser, it would be also helpful to see the difference in the request packets and how they are sent.

@stefan: Could you answer the question in c#7?  We need more information to make forward progress.

I'll try wireshark and get back to you in a few days!

Op 11 okt. 2016 6:49 p.m. schreef "rdsm… via monorail" <
monorail+v2.2679445682@chromium.org>:

Thank you for providing more feedback. Adding requester "kapishnikov@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

@stefan: Anything on that wireshark trace?

Closing the issue due to no feedback from the reporter. Please reopen the bug if the issue still exists.