Bug 125008 - Intermittent failures when using https with lighttpd 1.4.26
Summary: Intermittent failures when using https with lighttpd 1.4.26
Status: RESOLVED CONFIGURATION CHANGED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.9
: P2 Major
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2013-11-29 05:14 PST by Whitney
Modified: 2022-02-10 13:56 PST (History)
3 users (show)

See Also:


Attachments
Examples to reproduce (4.09 KB, application/zip)
2013-12-08 13:29 PST, Whitney
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Whitney 2013-11-29 05:14:11 PST
With Safari 7.0 for Mac OS X 10.9 Mavericks (specifically 9537.71), a web app that I work on started to have intermittent failures for Ajax requests through jQuery. This was never something that I was able to reproduce with Safari 7.0.

Environment:

  - Rails 4.0.0 (also 4.0.1)
  - jQuery Rails 3.0.4
  - jQuery 1.10.2

Request Details:

  - Uses UJS
  - Uses SSL
  - Not cross domain
  - The settings passed to the `ajax:beforeSend` UJS event [are here](https://gist.github.com/wbyoung/7697316).

## Intermittent Error

The `ajax:error` UJS event was triggered when the request failed. The error message was `SyntaxError: JSON Parse error: Unexpected EOF`. The XHR would have ready state of `4` with an empty response and status of `200`. There's [indication](http://stackoverflow.com/questions/4472051/jquery-json-request-gets-a-200-ok-answer-but-no-content) that this is due to the browser rejecting the request since it doesn't conform to the same-origin policy. This was in line what I saw on the server side — nothing. There was no matching request for the client IP that experienced this error; the AJAX request never made it to the server. Contrary to the idea of this being related to same-origin policy, though, these requests were made relative to the host (`/some/url`) so it absolutely should not fail the same-origin policy test & should not be subject to cross domain rules. Also, if this were related to a cross-domain issue, one would expect consistent failures. Interestingly, this seemed to happen consistently for certain users, but there were cases of them re-trying and things working properly later.

This issue happened for about 30% (ballpark) of requests with this specific version of Safari. It never happened with any other browser. This is a pretty critical part of the app, so I've been trying a slew of workarounds to what I'm assuming is a browser bug, but have yet to find any reports of such an issue.

## Attempted Fixes

Attempted fixes without success:

 - Originally the page's _GET_ and _POST_ URLs were the same, so I tried having the request post elsewhere.
 - I tried making the URL absolute instead.

These attempted fixes did not change anything.

Also, in diagnosing this problem, I used a basic AJAX request to post errors back to the server and get better reporting on what was going on. I noticed that some of these requests were failing as well (partial error reporting still helped in troubleshooting). So overall, it didn't seem like anything directly related to Rails, jQuery, or UJS.

## JSONP Solution?

Finally, I switched the request to use JSONP today, and it's been pretty successful. There was one failure, but that failure could have been for other reasons (still investigating).
Comment 1 Brady Eidson 2013-12-03 12:12:11 PST
Can you try with a WebKit Nightly?
Comment 2 Alexey Proskuryakov 2013-12-03 12:22:22 PST
> This was never something that I was able to reproduce with Safari 7.0.

Can you please confirm whether this is reproducible for you? Did you mean Safari 6?

Are there any redirects involved when fetching the resource?
Comment 3 Whitney 2013-12-03 12:46:26 PST
This is not reproducible for me. It occurred for multiple users of the web app, though.

I meant Safari 7.0 (9537.71).

As far as I know, there were no redirects involved in making the request. There should not have been, but there could have been something going on in the server configuration that I wasn't aware of. Would Safari show if it had handled a redirect?
Comment 4 Brady Eidson 2013-12-03 12:58:11 PST
(In reply to comment #3)
> This is not reproducible for me. It occurred for multiple users of the web app, though.
> 
> I meant Safari 7.0 (9537.71).
> 
> As far as I know, there were no redirects involved in making the request. There should not have been, but there could have been something going on in the server configuration that I wasn't aware of. Would Safari show if it had handled a redirect?

That's why I couldn't reproduce with the "test case"... we don't have a reproducible test case.

Saying "we've never been able to reproduce this but this happened to some users and we don't know under what circumstances" puts this in the "very difficult to explore" category.
Comment 5 Whitney 2013-12-03 13:56:46 PST
Indeed it does. I though it worthwhile to report, though. I've worked around this by using JSONP in the app, so I'm okay with this being closed. But I wanted to report it in case anyone had any ideas or in case anyone else happens to have the same problem.
Comment 6 Whitney 2013-12-08 13:29:47 PST
Created attachment 218711 [details]
Examples to reproduce
Comment 7 Whitney 2013-12-08 13:31:09 PST
The problem seems to have been in the web server, Lighttpd 1.4.26. I don't know if it's a bug on their end or in Safari. It's strange that this is the first time this has been a problem and is only a problem in Safari.

The problem was resolved by updating Lighttpd, though. I attached some files to show how to reproduce.
Comment 8 Alexey Proskuryakov 2013-12-08 18:36:33 PST
This is exciting news, thank you so much!

Could you please tell more about what was happening? It's not quite clear without steps to reproduce - seems like it's an interaction between multiple methods of accessing the root document (GET vs. POST and "/" vs. "index.html"). But there isn't even any XMLHttpRequest in this example.

So what would help the most:
1. Detailed steps to reproduce.
2. A tcpdump capture of the failure (if it's also reproducible without SSL).
Comment 9 Whitney 2013-12-08 19:52:06 PST
Sorry, I absolutely should have been more clear. I was in a hurry when I updated this before.

I've realized that the issue no longer has to do with an XMLHTTPRequest and instead has to do with POST requests via SSL.

To reproduce:

 - Install Lighttpd 1.4.26
 - run: cd example/server
 - run: lighttpd -f lighttpd.conf -D
 - Open example/test.html in Safari 7.0
 - Click "Send"

Expectation: POST request connects and completes immediately when connecting to the local server.

Actual result: POST request hangs and eventually returns an empty response.

Also, when testing, I just created an empty file at example/server/public/index.html, but if you put content in that you'll see more clearly that with Lighttpd 1.4.26 it return an empty response.
Comment 10 Alexey Proskuryakov 2013-12-09 23:42:01 PST
I can reproduce this. Seems like something below WebKit...
Comment 11 Alexey Proskuryakov 2013-12-09 23:42:23 PST
<rdar://problem/15624226>
Comment 12 Alexey Proskuryakov 2013-12-09 23:47:45 PST
I imported the bug for Apple's SSL experts to take a look. 

Note that SSL was quite broken in this release of lighttpd - for me, it didn't work at all until I applied a workaround from <http://fredericiana.com/2010/03/29/lighttpd-1-4-26-ssl-bug/>. But yes, it works with other browsers, so worth a look.