Is it possible litespeed has a problem with mobile safari ?

aww

Well-Known Member
#1
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.
 

mistwang

LiteSpeed Staff
#2
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. ;)
 

aww

Well-Known Member
#4
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.
 

aww

Well-Known Member
#5
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:

mistwang

LiteSpeed Staff
#6
you can turn off keepalive with rewrite rule, like

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

aww

Well-Known Member
#8
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.
 

aww

Well-Known Member
#10
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:

aww

Well-Known Member
#11
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:
Top