search

bottlepy / bottle

bottle.py is a fast and simple micro-framework for python web-applications.
http://bottlepy.org/
MIT License
8.38k stars 1.46k forks source link

Bottle and Android 4.0.4 #333

Open PeterVollmer opened 12 years ago

PeterVollmer commented 12 years ago

Requests from Adnroid 4.0 needs along time to be received and sometimes it looks like this:

192.168.178.25 - - [09/Jun/2012 22:10:27] "GET / HTTP/1.1" 404 725 192.168.178.25 - - [09/Jun/2012 22:10:37] "GET /l HTTP/1.1" 404 727 192.168.178.25 - - [09/Jun/2012 22:10:47] "GET /la HTTP/1.1" 404 729 192.168.178.25 - - [09/Jun/2012 22:10:57] "GET /lam HTTP/1.1" 404 731 192.168.178.25 - - [09/Jun/2012 22:11:07] "GET /lamp HTTP/1.1" 404 733 192.168.178.25 - - [09/Jun/2012 22:11:17] "GET /lamp/ HTTP/1.1" 404 735 192.168.178.25 - - [09/Jun/2012 22:11:27] "GET /lamp/s HTTP/1.1" 404 737 192.168.178.25 - - [09/Jun/2012 22:11:37] "GET /lamp/se HTTP/1.1" 404 739

Especially I've doing only HttpUrlConnections.

niklas88 commented 12 years ago

I can confirm this bug with my Galaxy Nexus and the built in wsgiref server. Doing the same request to an "nc -l -p 8080" doesn't show anything special and it's instant. The issue happens with an Android App using HttpUrlConnection as well as with Chrome Beta. By the way, this is using bottle with python 3.2.3

defnull commented 12 years ago

Could be some header the HttpUrlConnection chokes on. Or a bug in the handling of range requests. Or... actually I have no idea :/

niklas88 commented 12 years ago

The problem seems to be on the bottle site and it happens with Chrome Beta as well as with HttpUrlConnection, there are also no range headers. Sending the request to netcat I get fot the HttpUrlConnection:

 GET /lamp/setColor?rgb=ff0000 HTTP/1.1
 User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.0.4; Galaxy Nexus Build/IMM76I)
 Host: 192.168.178.21:8080
 Connection: Keep-Alive
 Accept-Encoding: gzip

With Chrome Beta I get:

 GET /lamp/setColor?rgb=ff0000 HTTP/1.1
 Host: jupiter.fritz.box:8080
 Connection: keep-alive
 Cache-Control: max-age=0
 User-Agent: Mozilla/5.0 (Linux; Android 4.0.4; Galaxy Nexus Build/IMM76I) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Encoding: gzip,deflate,sdch
 Accept-Language: en-US,en;q=0.8
 Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

I'd suspect that it could have something todo with how the request might not be in a single IP packet because of Wifi so it might be that wsgiref has some code that expects to get the whole header with a single read.. This is only my gut feeling though

defnull commented 12 years ago

That is unlikely. The byte sizes in PeterVollmers logs match the typical size of a bottle error page, but bottle is not involved until all headers are sent and parsed by the WSGI server, and the server does not end header-mode until it hits a blank line.

So, somehow, the server gets more than one (valid) request, or thinks it does.

niklas88 commented 12 years ago

Note that the same bottle app works when running in tornado. Both mine and Peter's with Chrome Beta.and HttpUrlConnection

defnull commented 12 years ago

Any news on this? I am curious

jamesbennet commented 11 years ago

I think its due to google's instant search feature, which tries to get the page while you are typing it?

mwkaufmann commented 11 years ago

Man, I had this issue a year ago and thought it was a network problem.

I am trying to reproduce this and do some low level wireshark debugging. So far I haven't succeed in reproducing, but I will keep an eye on it.

horribleperson commented 4 years ago

Can this bug be closed? It has not been updated in a long time, and makes reference to a version of Android that has long been obsoleted.