EventSource does not work with 127.0.0.1 adresses
Reported by
bennikl...@aon.at,
Dec 3
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0 Steps to reproduce the problem: 1. Use any tool that provides an endpoint for server sent events, e.g. clone the repository https://github.com/klues/tutorials 2. if you use my repository, cd to folder 'spring-boot-reactive-sse' and run 'gradle bootRun' -> starts an SSE endpoint. 3. Open Chrome on any page and go to console (Ctrl-Shift-I) 4. Insert the following code snippet to console: var _eventSource = new EventSource('http://localhost:8080/stock/transaction'); _eventSource.onmessage = function(data) {console.log(data)} setTimeout(function() {_eventSource.close()}, 5000); 5. Some data from the SSE endpoint we started in (2) will be printed on console. 6. Now try the same code snippet with '127.0.0.1' instead of 'localhost'. 7. No data is printed to console, also no error message. 8. Try the same from OS commandline: 'curl -v http://127.0.0.1:8080/stock/transaction' -> works without problems What is the expected behavior? Connecting to a SSE source should also work with the adress '127.0.0.1'. What went wrong? Opening an EventSource with any '127.0.0.1' address does not return any data, also no error message. Did this work before? N/A Does this work in other browsers? No Same problem in Firefox but I think because of a differenct bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1376310 Exaclty the same behaviour in Opera. Not applicable for Edge/IE because they do not support SSE. Chrome version: <Copy from: 'about:version'> Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 18.0 r0 I'm using '127.0.0.1' instead of 'localhost' because Firefox only allows requests to '127.0.0.1' from a secure context, see https://developer.mozilla.org/en-US/docs/Web/Security/Mixed_content#Warnings_in_Web_Console
,
Dec 3
,
Dec 4
I cannot reproduce. I have not tried the supplied example, as I do not have a suitable environment. However, there are a number of Blink tests which connect back to 127.0.0.1 and pass, for example https://cs.chromium.org/chromium/src/third_party/blink/web_tests/http/tests/eventsource/eventsource-parse-event-stream.html?q=eventsource-parse-event-stream.html If there was a CORS issue, I would expect an error to appear on the console. But I don't have any other guesses what the problem might be. If possible, a network dump captured like https://www.chromium.org/for-testers/providing-network-details might help diagnose the problem.
,
Dec 4
,
Dec 4
attached two network dump logfiles, one for the test with "localhost" (working), another for "127.0.0.1" (not working). This is the console log of both tests: http://prntscr.com/lqm4dl
,
Dec 5
just saw the following difference in the network log of devtools: 1) 127.0.0.1: http://prntscr.com/lr3u67 --> "Provisional headers are shown" 2) localhost: http://prntscr.com/lr3u1n --> all request details are shown
,
Dec 6
All I was able to determine from the netlog was that Chrome never receives a response to the request to port 127.0.0.1. Here are the exact headers sent to 127.0.0.1:8080: Host: 127.0.0.1:8080 Connection: keep-alive Pragma: no-cache Cache-Control: no-cache Accept: text/event-stream Origin: chrome-search://local-ntp User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36 Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9,de-DE;q=0.8,de;q=0.7,es;q=0.6 Could you use curl -H to send a request to the server with these exact headers and see if it makes any difference? #6 The reason for the "Provisional headers are shown" message is that devtools isn't notified of the final request headers until a response is received. Since the netlog shows no response being received, this makes sense.
,
Dec 6
here the curl command with exactly these headers: http://prntscr.com/lrlqrw --> works as expected
,
Dec 7
#8 Thank you. This is very strange. Is it possible the server can only handle one request at a time?
,
Dec 7
,
Dec 7
>> Is it possible the server can only handle one request at a time? << no, just started 3 instances of curl parallel -> all working.
,
Dec 7
#11 Thanks. I can't explain it. What I would try next if I could run the repro would be to use a network sniffer such as Wireshark to check whether the request from Chrome is reaching the server. If you are comfortable with tools like Wireshark before then you could try it.
,
Dec 10
tried to capture the traffic with "RawCap" (see https://wiki.wireshark.org/CaptureSetup/Loopback#IP_127.0.0.1 ) with these results: Recorded the traffic for the curl and the Chrome connection to 'http://localhost:8080/stock/transaction'. Both recordings included the line: 1) Chrome@Time: 1.005368 --> HTTP OK with JSON response from server 2) curl@Time: 2.375072 --> HTTP OK with JSON response from server see attached pcap files to confirm. So it seems that Chrome does not process the response for whatever reason.
,
Dec 10
sry, the connection was to 127.0.0.1, not to localhost in #13
,
Dec 12
#13 Thank you for the pcap traces. It appears that Chrome closed the connection after receiving the response. I can find no explanation. I am going to try harder to create a reproduction environment locally.
,
Dec 12
ok, should not be too hard to reproduce the environment: 1) install gradle: https://docs.gradle.org/current/userguide/installation.html 2) follow the steps from post #1
,
Dec 12
#16 Thanks. I had to fix some compile errors using delombok, but apart from that it ran fine. Unfortunately, I can't reproduce the issue. This was on Windows 10, Chrome version 71.0.3578.80 (latest stable), Java version 1.8.0_162-b12. The connection to 127.0.0.1:8080 worked the same as localhost:8080. One thing I noticed in the netlog is that the "localhost" variant used the IPv6 address for localhost. It would be interesting to try using the URL http://[::1]:8080/stock/transaction to see if it works.
,
Dec 12
Thanks for trying to reproduce - strange that you could not reproduce it. Here my current version details: Chrome: 71.0.3578.80 (latest stable) Win 10: Build 17134.407 Java: 1.8.0_151-b12 I cannot imagine that the slightly different java version makes any difference. Also tried to open EventSource with "http://[::1]:8080/stock/transaction" -> worked fine. Just "127.0.0.1" is not working.
,
Dec 12
just tried the same setup on two virtual machines (Win7 and Win10), both worked with 127.0.0.1 and localhost. So the issue somehow seems to be related with my configuration - but I don't have a clue what it could be. Not sure if this issue can be closed because somehow it seems to be related with Chrome (works in curl, not in Chrome), but only in my setup...
,
Dec 13
I think you probably have some software on your computer which hooks into Chrome and interferes with connections to 127.0.0.1. Various kinds of security software like to interfere with Chrome's network stack. If "http://[::1]:8080/stock/transaction" works in Firefox, that would solve your compatibility issue. I'm going to mark this issue "WontFix" as I don't think there's anything we can do about this in Chrome.
,
Dec 13
just disabled my antivirus and tried "127.0.0.1" in Chrome -> still did not work. I have no clue what the problem is, but as long as it is just on my current system it's not that bad. also tried "http://[::1]:8080/stock/transaction" in Firefox -> it worked! Thanks for the suggestion, crazy that both "localhost" and "127.0.0.1" do not work in FF, but "[::1]" does. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by kl...@live.de
, Dec 3