So, I am currently working on a home automation project using an Arduino + Ethernet shield which is used as a web server. The webpage on the Arduino uses basic Ajax to send requests without refreshing the page or adding anything after the URL.
Here is the script:
<script type="text/javascript">
function GetArduino(url) {
var request = new XMLHttpRequest();
request.open("GET", url , false);
request.send();
}
</script>
In the HTML page I use the following to send the requests:
I then read out the HTTP requests on the Arduino and use the "L=XX" code to activate the proper lights or blinds in my house.
Now for the problem:
When using the webpage on my iPhone, every HTTP request is send 3 times in a row. This results in my lights going ON -> OFF -> ON when using Safari on my iPhone. When using Chrome on the same device, this doesn't happen.
The HTTP request looks like this on the Arduino (3 times):
new client
GET /?L=29 HTTP/1.1
Host: 192.168.1.177
Referer: http://192.168.1.177/
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en-us
Connection: keep-alive
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_1 like Mac OS X) AppleWebKit/537.51.2 (KHTML, like Gecko) Version/7.0 Mobile/11D167 Safari/9537.53
I also noticed that Chrome does the same thing (triple HTTP request) the first time the page is loaded. After that, everything is fine.
I'm no expert in programming, so I'm probably overlooking something obvious here?
OK, this is embarrasing.... Turns out I was overlooking something obvious!
After searching the solution for several days (and nights!), the moment I decide to try my luck here, I find the solution.
Apparantly I had to acknowledge the request in the Arduino code:
client.println("HTTP/1.1 200 OK");
client.println();
Still strange that different browsers/devices handle this differently.
Related
I've got a problem with an Ajax request in my web project. Most of the time it works just fine but sometimes there is simply no request from the client (it does not show in wireshark), FireBug just shows the request marked red.
Project looks like the following:
Java Backend with JSPs, Client is using the Firefox Browser
The request is done via prototypejs using the Ajax Updater function. I can debug the request preparation via firebug until the Ajax Update function fires the request but then no request is listed in my wireshark output (although all other request are listed just fine).
So I have a (sometimes) vanished Ajax request with no error and no clue where to look :( Any help would be much appreciated.
Request:
[...]/ajax/gruppe/loadTreeList.do?ajax=true&tstamp=645&context=GRUPPE&level=0&itemid=0
RequestHeader:
Accept text/javascript, text/html, application/xml, text/xml, /
Accept-Encoding gzip, deflate
Accept-Language de-de,de;q=0.8,en-us;q=0.5,en;q=0.3
Connection keep-alive
Cookie JSESSIONID=326D8AEAAFD254760CEC8D050734807E
Host localhost:8080
Referer [...]/domain/druck/gruppe.do
User-Agent Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20100101 Firefox/17.0
X-Prototype-Version 1.7.1
X-Requested-With XMLHttpRequest
There is no response.
I have a strange problem with JMeter.
I've made recording of some sort of web application without any problems. Problem appears during playback of test.
For some reason I receive different results during playback than during recording.
When I compare Http Request made during recording and playback I don't see a single difference (except for some security token which I'm extracting from earlier requests and passing as parameter).
To be more exact during recording I receive a response with a big body (>5kB), and during playback body of response is empty. Response code is 200 (OK).
This body contains crucial data from database, so I'm afraid that measurement made by this JMeter script will not reflect actual behavior of application, simply I will not measure what I really need.
Now my questions:
is there some tool or JMeter plug-in which will allow more effectively see contents of HTTP requests and its responses? It would be great If I could compare of requests made during recording and playback. So far I used two listeners: "View Results Tree". I've sandwiched between them to compare request from recording and playback.
is there some known bug in JMeter which could explain the difference? For example something related to recording process?
Here is example of request:
POST http://10.133.27.81:8080/c/portal/render_portlet
POST data:
p_l_id=69210&p_p_id=blank_WAR_Blank_INSTANCE_iNM3&p_p_action=0&p_p_state=normal&p_p_mode=view&p_p_col_id=column-2&p_p_col_pos=1&p_p_col_count=2
[no cookies]
Request Headers:
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Accept-Language: pl
Accept: */*
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
csrf_token: 1GXK-0QD7-GFPJ-JLDG-JP2G-J390-BFLG-7LL7
Pragma: no-cache
Method: POST /c/portal/render_portlet HTTP/1.1
X-Requested-With: OWASP CSRFGuard Project
Referer: http://10.133.27.81:8080/group/bou
Accept-Encoding: gzip, deflate
Content-Length: 143
Host: 10.133.27.81:8080
Update: to make sure which headers or parameters are constant I made 4 recordings of same test case during different sessions and compared them, so I'm quite sure that only csrf_token has to be field with value fetched from other request. I've added debug sampler to verify that this value is fetched properly.
Update 2: Problem found.
There where two problems:
There is a bug in JMeter when you do a search (Ctrl-F) it searches the whole project except for HTTP Header Menagers and my request contained csrf_token inside of header (I detected that before posting this question). Making a search in xml using text editor was good workaround for that.
when I try to find source of problems, before I've found problem number one, I've added a new problem by removing a HTTP Cookie Manager (I'm blaming myself and IE for this).
Generally changing Internet Explorer to FireFox with HttpFox add-on help to spot the problem.
Thanks everyone for support.
Marek
Response code 200 doesn't have to mean that everything went well at the application level.
To find out more details you can use Debug sampler and Debug PostProcessor.
Example here.
Your issue comes certainly from a missing dynamic request parameter that you didn't compute.
Look for example at csrf_token header Did you make it variable? Or do you transmit its initial recorded valur, but also at any parameter that contains some hashdata or numeric data referencing some content that does not exist in your page or request.
For example col pos I see p_p_col_id and related parameters, are you sure they reference something in your replay.
There is really very little chance of a JMeter bug in this case.
I am trying to do an AJAX call to an external domain. After reading a little bit, I have realised that this cannot be done. And I was starting to dive into proxys solution, but then I've found info about "cross-site xmlhttprequest with CORS"
Then, from here I have understood that perhaps non-old browsers had already implemented a way to do it, as far as the target domain allowed it I guess.
So, within this obscurity, I have decided to check the HTTP headers that were being captured.
It is a GET petition
http://www.genome.jp/dbget-bin/www_bconv?dbkey=uniprot&acc=P11730
Using any broswer I get the web page that I want, but through the AJAX call I get an status of 0.
But, with the AJAX script and using the firefox add-on Live HTTP headers, I can see that everything seems to go all right
http://www.genome.jp/dbget-bin/www_bconv?dbkey=uniprot&acc=P62071
GET /dbget-bin/www_bconv?dbkey=uniprot&acc=P62071 HTTP/1.1
Host: www.genome.jp
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: null
HTTP/1.1 302 Found
Date: Sat, 28 Jan 2012 19:24:24 GMT
Server: Apache
Location: /dbget-bin/www_bget?mmu:66922
Content-Length: 0
Keep-Alive: timeout=60, max=1000
Connection: Keep-Alive
Content-Type: text/plain
So, there are 2 options:
1) it is working, but the code has some kind of error
2) It seems to be working, but actually AJAX cannot be done to an external domain. Why Live HTTP headers is capturing the good stuff? because the censorship is done afterwards.
What is the answer?
(javascript code)
<html>
<head>
<script type="text/javascript">
function loadXMLDoc()
{
var xmlhttp;
xmlhttp=new XMLHttpRequest();
xmlhttp.onreadystatechange=function()
{
alert(xmlhttp.readyState+' '+xmlhttp.status)
if (xmlhttp.readyState==4)
{
alert(xmlhttp.responseText);
}
}
if("withCredentials" in xmlhttp)
{
xmlhttp.open("GET","http://www.genome.jp/dbget-bin/www_bconv?dbkey=uniprot&acc=P11730",true);
xmlhttp.withCredentials = "true";
xmlhttp.onreadystatechange = handler;
xmlhttp.send();
}
}
</script>
</head>
<body>
EDIT: So it is like that to use CORS the extra header needs to be enabled on the web server. Then I assume it is option 2).
Interesting links
Ways to circumvent the same-origin policy
http://anyorigin.com/
http://enable-cors.org/
http://remysharp.com/2011/04/21/getting-cors-working/
Your assumptions are correct.
Contrary to popular belief, an XMLHttp request to an external domain can always be sent. But, javascript does not grant access to the response document.
This is due to the Same Origin Policy
The same origin policy prevents a document or script loaded from one origin from getting or setting properties of a document from another origin.
As you found out, if the server agrees to grant access by setting an according header, this restriction does not apply (provided the browser supports CORS too).
This problem has been puzzling me all morning; essentially I've reduced it down to a simple php page that generates a form and posts the results back to itself to narrow down the issue.
I've tested my problem on a couple of systems, XP, and Win7, both fully. When submitting a form using a POST action on my company Intranet, Safari doesn't seem to receive any POST data, the headers suggest it is being sent, but the page doesn't receive it.
It works fine in Opera, Chrome, IE8,9 and FF 6.0.1 and Safari on a Mac, but not Safari 5.1 + Windows. I'm think it may be related to our Intranet NTLM authentication, but I'm somewhat stumped. Hopefully it's a very daft/easy problem to solve.
Here are some headers from Safari Web inspector when posting to the Intranet:
Request URL:http://intranet/mis/basictest.php
Request Method:POST
Status Code:200 OK
Request Headers
Accept:text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8
Content-Type:application/x-www-form-urlencoded
Origin:http://intranet
Referer:http://intranet/mis/basictest.php
User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.50 (KHTML, like Gecko) Version/5.1 Safari/534.50
Form Data
test:1
submit:Submit
Response Headers
Connection:close
Content-Type:text/html
Date:Thu, 13 Oct 2011 10:55:55 GMT
Server:Microsoft-IIS/6.0
X-Powered-By:PHP/5.2.2, ASP.NET
Say, there's a URL, http://www.example.com/#hello.
Will the #hello thing be sent to the web server or not, according to standards?
How do modern browsers act?
The answer to this question is similar to the answers for Retrieving anchor link in URL for ASP.NET.
Basically, according to the standard at RFC 1808 - Relative Uniform Resource Locators (see Section 2.4.1), it says:
"Note that the fragment identifier is not considered part of the URL."
As stephbu pointed out, "the anchor tag is never sent as part of the HTTP request by any browser. It is only interpreted locally within the browser".
The hash variables aren't sent to the web server at all.
For instance, a request to http://www.whatismyip.org/#test from Firefox sends the follow HTTP request packet
GET / HTTP/1.1
Host: www.whatismyip.org
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Cache-Control: max-age=0
You'll notice the # is nowhere to be found.
Pages you see using # as a form of navigation are doing so through javascript.
This parameter is accessible though the window.location.hash variable
The anchor part (after the #) is not sent to any $_SERVER variables in PHP. I don't know if there is a way of retrieving that piece of info from the URL or not (as far as I know, it's not possible). It's supposed to be used by the browser only to find a location in the page, which is why the page does not reload if you click on an anchor like so: hello