Lighttpd

Please add these to your lighttpd.conf

debug.log-request-header = "enable" 
debug.log-response-header = "enable" 

and then look in the lighttpd error log to see what is sent and received in HTTP headers when the iOS device makes a request. If you can, post that info here or in a pastebin.

gstrauss, thanks for your reply.

attached you find the log.

regards

Thanks for the log. We can see that the response is the same for both iPad and Mac OSX desktop. It looks like this is an issue with the client properly handling 204 No Content, which need not include Content-Length. (lighttpd is RFC compliant here; this is not an issue with lighttpd)

The connections in the log are HTTP/1.1 keep-alive connection, as requested by the client. As you noted, #2537 might be related and give some hints as to how to workaround this. You're running lighttpd 1.4.35 (which is over two years old, BTW), but does parse "Connection" response header from CGI. Therefore, you might test by modifying x10-heyu-switch-nofeedback.cgi to add "Connection: close" to the response headers from the CGI. If this makes the issue go away, then at least we've identified the issue.

You might also check to see if there are any software updates for the iPad, since you reported that things are working with the desktop, which is Mac OSX, and running a later version of AppleWebKit and Safari than that running on the iPad (at least according to User-Agent strings in the log you provided).

thanks for the hints !

tried to add "Connection: close" => didn't change behavior on iPad :-(

meanwhile i tested the cgi with an android mobile => perfect, as on desktop.

before i had my home automation homepage hosted on an nslu2 device under unslung.
i believe, i used xs-httpd server and there was the 204 on iPad (same iOS version) OK.

lighty v1.4.35 is under raspbian the actual version in apt...

any other hints ?

regards

any other hints ?

meanwhile i tested the cgi with an android mobile => perfect, as on desktop.

All things continue to point to the version of browser on your iPad mishandling the 204 No Content response.

before i had my home automation homepage hosted on an nslu2 device under unslung.
i believe, i used xs-httpd server and there was the 204 on iPad (same iOS version) OK.

You might take a look at the HTTP response headers generated by xs-httpd to see how it differs from the lighttpd 204 No Content response.

RFC 7230 is explicit that there should be no Content-Length or Transfer-Encoding send with a 204 No Content:

A server MUST NOT send a Transfer-Encoding header field in any
response with a status code of 1xx (Informational) or 204 (No
Content).

...

A server MUST NOT send a Content-Length header field in any response
with a status code of 1xx (Informational) or 204 (No Content).

...

 1.  Any response to a HEAD request and any response with a 1xx
     (Informational), 204 (No Content), or 304 (Not Modified) status
     code is always terminated by the first empty line after the
     header fields, regardless of the header fields present in the
     message, and thus cannot contain a message body.

As an alternative, your CGI script might detect the iPad by checking the User-Agent string in the request header, and send a 302 Found with a Location equivalent to the Referer request header (or wherever else you want to send the client)

Reminder: please check if there are software updates to the iPad. That might resolve your issue, too.

gstrauss, thanks again for your hints.

i tried two other browsers on iPad.
firefox and chrome. same erroneous behavior :-(

i can't look @ the xs-httpd logs, because nslu died some days ago. rip.

on the used ipad3, iOS 9.x is last published version, so an iOS update is not possible.

regards

You should be able to update Firefox and Chrome on the iPad. Please update and see if you still have issues.

I am not familiar with the ipad, but if all browsers are forced through a proxy and the proxy mishandles 204 No Content, then that could also be an issue. Are you running any antivirus or other application-level firewalls on the iPad which might be outdated?

http://stackoverflow.com/questions/16720089/safari-on-ipad-incorrect-handling-of-http-status-code-204 says:

I have searched for similar problems and only found a reference to an old webkit bug from 2008 where the code was described as rendering a blank page when receiving a 204.

@stefan1, sorry, but you need to resolve this on your own. The problem is with (some) software on your iPad and needs to be updated. If there is no way to update it, then perhaps your money is better spent on devices for which updates are both available now and also likely to remain available for the serviceable lifetime of the device.

Webkit bug (2011/2012)
https://bugs.webkit.org/show_bug.cgi?id=60206
https://bugs.webkit.org/show_bug.cgi?id=104865

Chrome bug (2014)
https://bugs.chromium.org/p/chromium/issues/detail?id=368717

http://raspberrywebserver.com/gpio/piface/building-a-remote-control-vehicle-using-a-raspberry-pi.html
(search for "204" on the page, including in the comments)

mni tnx 4 your hints.

actually it looks like, that "Opera Coast" handles the 204 in an almost correct manner :-D
it seems, that it has to be a browser which does NOT use the apple webkit implementation...

cheers