Is it possible litespeed has a problem with mobile safari ?

Discussion in 'Feedback/Feature Requests' started by aww, Feb 10, 2011.

  1. aww

    aww New Member

    I could be wrong but I am seeing strange, much longer page load times on mobile Safari from an iphone when connecting to litespeed 4.0.x

    There are some subtle differences in Safari on iphone. Perhaps there is a timeout issue.

    Does anyone have an easy way to test the same content from apache vs litespeed off their iphone?

    I don't want to start "pointing fingers" until I have more data.

    I know Chrome on Android is not experiencing any problems and it's also webkit based but there are definitely core differences between the two browsers.
  2. mistwang

    mistwang LiteSpeed Staff

    You can try "tcpdump" on server side.
    First, find out the IP of your iPhone.
    Then run command

    tcpdump -s0 -X host <ip_of_your_iphone>

    think it is just the poor AT&T wireless network. ;)
  3. aww

    aww New Member

    If you don't mind I am going to PM you with some charts.
  4. aww

    aww New Member

    I turned off "smart keep alive" just to see if it makes any difference.

    I am seeing roughly a 50% speed improvement, but it make be a fluke of course.

    I will repeat the test late night on a weekend to see if super low traffic on their networks makes a difference.
  5. aww

    aww New Member

    I think I found the problem, maybe, mobile Safari is being picky.

    LiteSpeed sends a Connection: Keep-Alive when the source is php output and does not allow php to override?

    However the last thing I send on the page is a tracking gif, which I send as embedded packed hex, with header('Content-Type: image/gif') Content-Length: 43 and most importantly header('Connection: close')

    The Connection: close is being removed/overwritten by litespeed with keep-alive, so safari keeps waiting for up to 5 seconds before it times out (or litespeed does).

    How can I force litespeed to close the connection from php when I want it to?

    (note that other browsers do not seem to have this problem so I am not blaming litespeed)

    Code:
    HTTP/1.1 200 OK
    Date: Fri, 11 Feb 2011 07:26:57 GMT
    Connection: Keep-Alive
    Keep-Alive: timeout=5, max=100
    Content-Type: image/gif
    Content-Length: 43
    
    Last edited: Feb 11, 2011
  6. mistwang

    mistwang LiteSpeed Staff

    you can turn off keepalive with rewrite rule, like

    RewriteCond %{HTTP_USER_AGENT} iphone_user_agent_signature
    RewriteRule . - [E=nokeepalive:1]
  7. aww

    aww New Member

    Last edited: Feb 11, 2011
  8. aww

    aww New Member

    Sadly this does not seem to be working.

    Keep-Alive is still being sent

    Even took out the condition and just tried by itself

    RewriteRule . - [E=nokeepalive:1]

    maybe it has to do with sending a different kind of Content-Type header from PHP which is making litespeed ignore it?

    I'll try it on a plain PHP page.
  9. mistwang

    mistwang LiteSpeed Staff

    Are you sure rewrite is properly enabled? maybe enable rewrite log.
  10. aww

    aww New Member

    A little later I am going to create a minimal testing environment to see what exactly is happening.

    By the way, I don't suppose PUTENV can be used within PHP to send the same command?

    http://php.net/manual/en/function.putenv.php

    ie. putenv("nokeepalive:1") or maybe putenv("nokeepalive=1")

    not sure even apache will obey that.
    Last edited: Feb 11, 2011
  11. aww

    aww New Member

    Oh this is interesting.

    In my minimal test it works just fine and properly closes the connection.

    In the full test, the connection is sent keep-alive on the response.

    Same directory, all other headers are the same, being sent and being received, except for the keep alive

    Both are php programs emulating a gif image.

    Clearly I need to investigate more.

    Just discovered if I call the main program with the full index.php name the connection is properly closed.

    But if called just by the sub-directory ending in / it does a keep-alive

    I would guess there is a lower rewrite rule that is causing havoc.

    Why should a rewrite rule unset the connection: close though?
    Last edited: Feb 11, 2011
  12. webizen

    webizen New Member

    please turn on rewrite logging (log level -> 9) to find out why.
    Last edited: Feb 12, 2011
  13. webizen

    webizen New Member

    You can try below (. -> .*) as '/' doesn't match '.' but '.*'

    RewriteRule .* - [E=nokeepalive:1]

Share This Page