thanks, that helped!
Printable View
thanks, that helped!
Hi Johan,
Here's what I've found.
When POSTing, does it make a difference if you use different browsers?
I hadn't tried anything but firefox, but I've done some investigation and here's what I've got.
Firefox 2.0.0.11 (Windows XP)
Fails with 400 Error - Bad Request
IE 7.0.5730.11 (Windows XP)
Works Fine
n95 Built in Browser (on n95)
Doesn't fail with a response, but also doesn't send any POST data thru.
Opera 8.65 Build 9712 (on n95)
Works Fine
Is that behaviour consistent - is it always like that or just occasionally?
The behavior is consistent within each browser. i.e. each time I try a post on Firefox, I get a Bad Request.
What device do you have?
N95 Original
Which Open-C version did you install; the first release, or the second?
The openc_ssl.sis contained in pamp_with_htdocs_on_e.zip (v 0.01.00)
Do you access over WLAN or using the Raccoon or MWS gateway?
WLAN
If WLAN, do you use an ad-hoc connection or infrastructure?
Both
The main reason i'm trying to POST is that I've developed
a PHP file editor application that will allow easier development
of PAMP software using a standard browser. A GET request will work, but there's an underlying limit to how much data can be sent using GET
Thanks for your help
Gavin
This is awesome!
Did anyone get phpmyadmin working?
It's bugging out on me.
Already tried an .htaccess file with the following
session.save_path c:/system/temp/
session.save_handler user
session files get created by remain at 0 bytes.
Any ideas?
Johan F.
[QUOTE=gwmitchell;381496]
[ ... ]
n95 Built in Browser (on n95)
Doesn't fail with a response, but also doesn't send any POST data thru.
[ ... ]
[/QUOTE]
That's what I thought, see my [URL="http://discussion.forum.nokia.com/forum/showthread.php?t=125574"][U]2nd known issue over here[/U][/URL].
Johan F
Hi Gavin,
[QUOTE=gwmitchell;381496]
Is that behaviour consistent - is it always like that or just occasionally?
The behavior is consistent within each browser. i.e. each time I try a post on Firefox, I get a Bad Request.
[/quote]
Ok, my bet is that Firefox sends the HTTP request in multiple TCP/IP packets, while Opera and IE sends it in one. That should be irrelevant, of course, but could be an explanation, in which case we are talking about a bug in the web server.
If you feel an itch to investigate further, install [url=http://www.wireshark.org/]Wireshark[/url] (former Ethereal) on your PC and check what goes over the line.
[quote]
What device do you have?
N95 Original
[/quote]
If you havn't updated the firmware to the latest version, you could try if that would change anything.
[quote]
Which Open-C version did you install; the first release, or the second?
The openc_ssl.sis contained in pamp_with_htdocs_on_e.zip (v 0.01.00)
[/quote]
The SIS files included in the zip are from the second release. If you feel like experimenting you could try downloading the first Open C release, install the SIS files from there and see whether anything changes. At least local browsing should not work at all:)
[quote]
The main reason i'm trying to POST is that I've developed
a PHP file editor application that will allow easier development
of PAMP software using a standard browser.
[/quote]
That's great - hopefully we can sort these problems out.
Johan
[QUOTE=jhnwkmn;381863]Hi Gavin,
Ok, my bet is that Firefox sends the HTTP request in multiple TCP/IP packets, while Opera and IE sends it in one. That should be irrelevant, of course, but could be an explanation, in which case we are talking about a bug in the web server.
If you feel an itch to investigate further, install [url=http://www.wireshark.org/]Wireshark[/url] (former Ethereal) on your PC and check what goes over the line.
[/QUOTE]
Ok, from what I've found using ethereal, it looks like you're correct, Firefox does send it's POST data in multiple TCP packets. 1 Packet for the Headers and 1 for the payload / form data. IE Sends both sections in one packet.
[QUOTE=jhnwkmn;381863]
If you havn't updated the firmware to the latest version, you could try if that would change anything.
[/QUOTE]
I'm currently on 20.0.015 (Although, there's rumours about a
[url=http://feeds.symbian-guru.com/%7Er/symbianguru/posts/%7E3/225999292/new-firmware-for-n95-n95-8gb-coming-soon.html]21.0.001 Version[/url] knocking around
[QUOTE=jhnwkmn;381863]
The SIS files included in the zip are from the second release. If you feel like experimenting you could try downloading the first Open C release, install the SIS files from there and see whether anything changes. At least local browsing should not work at all:)
[/QUOTE]
Will try this next ...
Thanks for your help
Gavin
[QUOTE=gwmitchell;383167]Ok, from what I've found using ethereal, it looks like you're correct, Firefox does send it's POST data in multiple TCP packets. 1 Packet for the Headers and 1 for the payload / form data. IE Sends both sections in one packet.
[/quote]
Thanks for verifying that - I will have to investigate this further.
Johan
Hi,
is there a plan for a php extension to access phone functions. that would take it beyond database applications for the platform!
[QUOTE=bmert;383754]Hi,
is there a plan for a php extension to access phone functions. that would take it beyond database applications for the platform![/QUOTE]
Such extensions exist already and are available in the release, so basically it's just the documentation that is missing. But that will be provided shortly.
Johan
[QUOTE=jhnwkmn;383318]Thanks for verifying that - I will have to investigate this further.
Johan[/QUOTE]
Do you have any news about this bug ?
I obtained the same faulty behaviour using E51's and N95-8GB's built-in web browser with Mobile Web Server (Raccoon) 0.11 (not the full PAMP stack, so maybe this is not the right thread !); the navigation occurs locally (apache is installed on the same phone where the browser is running); if you use the gw, everything works, since the gw/connector rejoins the TCP packets, but for local browsing using the gw is not so good :mad:
[QUOTE=tilab123;390280]Do you have any news about this bug?
[/Quote]
Yes. It actually seems that there is a problem with how Open-C handles a select with a timeout. I have a workaround, but I need to verify that something else is not broken by it.
Johan
[QUOTE=jhnwkmn;390288]Yes. It actually seems that there is a problem with how Open-C handles a select with a timeout. I have a workaround, but I need to verify that something else is not broken by it.
Johan[/QUOTE]
Just to make you know, and to be sure we are talking about the same problem, the "errors" you get when browsing locally by the built-in phone's webbrowser (e51 for example) are a bit different from the ones you get using firefox: since the phone's webbrowser breaks the post request differently, you don't even get any errors at all !
It seems that the bug (I don't know if it's the same one when using firefox, but it may be) makes the server miss the first byte of the second TCP segment so, this time (built-in browser), that first byte is the first char of the post data.
For example, using the following html page (test.html)
[html]
<html>
<head>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
<title>
Test (view params)
</title></head>
<body>
Test (view params)
<br><br>
<br>Post:<br>
<form action="index.py/test_show_params" method="post">
<input TYPE="text" name="msg"/><br>
<input type="hidden" name="hid_param" value="value of hidden param"/>
<input type="submit" value="Send">
</form>
</body>
</html>
[/html]
which calls the following python code (index.py)
[code]
# index.py
def test_show_params(req,**params):
req.content_type="text/html"
req.write("""\
<html>
<head>
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
<META HTTP-EQUIV="Expires" CONTENT="-1">
<title>
Test bad param name
</title></head>
<body>
Test bad param name
<br><br>""")
req.write("raw: "+str(params)+"<br>\n")
req.write("""\
</body>
</html>""")
[/code]
(put both files in dir apache/mod_pyhton/py/ of a standard Raccoon installation)
you get (when you go by the phone's browser to test.html and press send) a wrong name for the first post parameter: "sg" instead of the right "msg".
This behaviour is compatible with the error you get with firefox (this time the missing char is the one of the Content-Type header, the first "C", so you get a bad request error).
In the case of the bad parameter name, you can circumvent the problem (dummy first param), but if the break into TCP segments is made in a different place, .....
So, to summarize, are we talking of the same problem ?
[QUOTE=tilab123;390827]
...
So, to summarize, are we talking of the same problem ?[/QUOTE]
No we were not, but I was able to repeat this.
Thanks for pointing it out - I will look into it.
Johan
[QUOTE=jhnwkmn;391095]No we were not, but I was able to repeat this.
[/QUOTE]
Apparently the problems were the same after all, because the fix for the other problem also fixed this. Anyway, in the next release this should work the way it is supposed to.
Johan
[QUOTE=bmert;383754]
is there a plan for a php extension to access phone functions. that would take it beyond database applications for the platform![/QUOTE]
Please read this [url=http://discussion.forum.nokia.com/forum/showthread.php?t=129398]posting[/url].
Johan