Wt

An initial application load on an iPad can produce unstyled content with git version 3.3.0-10-g45b859b. This appears to be a regression from 3.2.3.

The issue can occur when there are network delays on a direct connection to a Wt httpd server (no proxy).

The problem can be reproduced with a sample Wt application such as "hello", an iPad (ios 6.1.3), and a mechanism for introducing network delay. For my testing, I used a Linux system running Debian Wheezy and introduced a system-wide delay on the eth0 interface with: "tc qdisc add dev eth0 root netem delay 100ms". Note: after testing, the delay was removed with "tc qdisc del dev eth0 root".

Here is the output log from the "hello" application with a 100ms (line numbers have been placed in the first column for reference):

 1 [2013-May-26 06:30:05.256932] 9221 - [info] "WServer/wthttp: initializing built-in wthttpd"
 2 [2013-May-26 06:30:05.257683] 9221 - [info] "wthttp: started server: http://0.0.0.0:8080"
 3 [2013-May-26 06:30:08.835058] 9221 - [info] "Wt: session created (#sessions = 1)"
 4 [2013-May-26 06:30:08.835686] 9221 [/hello YEfAyw45nDZkvxzh] [info] "WEnvironment: UserAgent: Mozilla/5.0 (iPad; CPU OS 6_1_3 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B329 Safari/8536.25"
 5 192.168.1.100 - - [2013-May-26 06:30:08.842975] "GET /hello HTTP/1.1" 200 2660
 6 [2013-May-26 06:30:08.843190] 9221 - [info] "WebRequest: took 8.893ms"
 7 192.168.1.100 - - [2013-May-26 06:30:08.974271] "GET /hello?wtd=YEfAyw45nDZkvxzh&request=style HTTP/1.1" 200 0
 8 [2013-May-26 06:30:08.974425] 9221 - [info] "WebRequest: took 1.419ms"
 9 192.168.1.100 - - [2013-May-26 06:30:09.119196] "GET /hello?wtd=YEfAyw45nDZkvxzh&sid=2112803716&htmlHistory=true&deployPath=%2Fhello&request=script&rand=511925196 HTTP/1.1" 200 42022
10 [2013-May-26 06:30:09.119344] 9221 - [info] "WebRequest: took 39.606ms"
11 192.168.1.100 - - [2013-May-26 06:30:09.208168] "GET /hello?wtd=YEfAyw45nDZkvxzh&sid=2112803716&htmlHistory=true&deployPath=%2Fhello&request=script&rand=511925196 HTTP/1.1" 200 41921
12 [2013-May-26 06:30:09.208224] 9221 - [info] "WebRequest: took 17.881ms"
13 192.168.1.100 - - [2013-May-26 06:30:09.660095] "POST /hello?wtd=YEfAyw45nDZkvxzh HTTP/1.1" 200 50
14 [2013-May-26 06:30:09.660239] 9221 - [info] "WebRequest: took 4.115ms"

Here is a description of what seems to be happening:

At line 7, Wt attempts to send an empty response to the style request (because the iPad is using noBootStyleResponse mode). Although not apparent from the log provided, the response is inconsistent since it has a "Content-Encoding: gzip" header, but contains zero bytes of content --- rather than the expected gzip-encoding of a zero-byte message. Note: This is a regression from 3.2.3 which produces 20-bytes of gzip-encoded output for the empty content.

The iPad appears to react to this inconsistent response by closing the connection to the Wt httpd server. Depending on timing, this may have no visible effect: additional server connections are created and the application starts-up normally.

However, in the presence of a network delay, it seems that the iPad may already have re-used the connection to send a pipelined GET request for the script (line 9), before detecting the problem with the style response. In this case, when the iPad closes the connection to the Wt httpd server, the response for the first GET of the script is discarded.

As a result, the iPad establishes a new connection and retries the GET request for the script (line 11). This second GET succeeds, but results in a different reply than for the first GET. The reply for the second GET does not contain the "Wt3_3_0.addStyleSheet(...)" calls needed to load the applications stylesheets. This may be a second regression, as I believe that Wt 3.2.3 would include the addStyleSheet calls even if the GET for the script was requested a second time.

I have tested a patch which addresses the first issue with gzip-encoding of zero-length content and will provide a link to it on github shortly. Please note that This patch will not address the second regression where subsequent GET requests do not include the addStyleSheet(...) calls.

If I can provide additional information, please let me know.