UI using Windows (Chrome/Firefox) doesn't load job results. about atc

[concourse-bot]

Hi there!

We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.

The current status is as follows:

• #134188117 UI using Windows (Chrome/Firefox) doesn't load job results.

This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.

[nichegriffy]

I am also experiencing this issue. I think I've narrowed it down somewhat.

First, some background: At my workplace, each machine is accessible as mycompany.<dev-name>. I am running the local vagrant VM on my Windows 8.1 machine and forwarding port 8080 from guest to 8080 on host. I am using Vagrant 1.9.1 and VirtualBox 5.1.14.

I can GET both http://localhost:8080/teams/main/pipelines/hello-world/jobs/hello-world/builds/2 and http://mycompany.griffy:8080/teams/main/pipelines/hello-world/jobs/hello-world/builds/2 in my browsers (Chrome/Firefox) on Windows. I can also GET the relevant text/event-stream directly at http://localhost:8080/api/v1/builds/2/events just fine. However, if I instead try to GET http://mycompany.griffy:8080/api/v1/builds/2/events, it will hang indefinitely.

To make things more interesting, my coworker who uses a Mac is able to GET http://mycompany.griffy:8080/api/v1/builds/2/events with no issues. The problem seems to happen solely on Windows browsers only when not accessing the event-stream via localhost.

Finally, there is one more interesting bit to all of this: If I ssh into the VM and kill -SIGINT the concourse process while I have an ongoing request to http://mycompany.griffy:8080/api/v1/builds/2/events on my machine, it will stop hanging and return the expected response.

It's as if the interrupt is triggering some kind of flush, but where in the stack that flush is happening I'm not sure...

Examples of the problem in action:

[nichegriffy]

I have confirmed the behavior we are experiencing at my workplace is not a bug with atc, but is instead a bug either with browsers on Windows or is the result of some system misconfiguration. Running the simple SSE server given in this SO answer demonstrates the same behavior: http://stackoverflow.com/a/26089932 . Namely, when accessing the page from localhost or 127.0.0.1, it works as expected, but when accessing it from a non-loopback address (IP or hostname), it hangs indefinitely. Notably, curl is able to access all pages successfully. @skyscooby Can you confirm that you experience the same problem with this server?

For people who might come across this issue looking for solutions, what we ended up doing as a quick workaround was running a simple proxy server (https://github.com/nodejitsu/node-http-proxy) on our Windows boxes that proxies traffic from 127.0.0.1 to the concourse web server so that the browsers will see a loopback address and be "fooled" into working correctly.

If someone finds a better solution or is able to pinpoint the true issue, please let me know!

[vito]

Moved to concourse/concourse#1125