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
Related
I have started using HP Loadrunner as part of a performance testing project.
We are trying to hit an initial URL which redirects to an identity server and then redirects to the web portal login screen.
For now I am trying in parallel to see the message exchange in both loadrunner log and browser log (just to compare the two request response messages). For some reason even though the initial HTTP GET message seems to be the same as the browser one the response coming back from the web portal is not the same. So at the location property when i get the rediction url the path is missing the port number at the redirect_uri point (...../url:portnumber2/.....). that creates an issue with the second redirection as instead of getting me to the proper redirection url it takes me to the error page redirection.
so the message exchange in browser looks like below:
Request URL:https://urladdress:portnumber1/
Request Method:GET
Status Code:302
Remote Address:10.33.5.83:4020
Referrer Policy:no-referrer-when-downgrade
Response Headers
content-length:0
date:Fri, 25 Aug 2017 06:50:47 GMT
location:/connect/authorize?client_id=...&redirect_uri=https%3A%2F%2Furladdress%3Aportnumber%2F....sign........
server:.......
set-cookie:.AspNetCore.OpenIdConnect........
set-cookie:.AspNetCore.........
status:302
x-powered-by:ASP.NET
x-ua-compatible:IE=Edge,chrome=1
Request Headers
:authority:urladdress:portnumber1
:method:GET
:path:/
:scheme:https
accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding:gzip, deflate, br
accept-language:en-US,en;q=0.8
upgrade-insecure-requests:1
user-agent:.......
second redirection
Request URL:https://urladdress:portnumber2/connect/authorize?......
Request Method:GET
Status Code:302
Remote Address:ipaddress:portnumber2
Referrer Policy:no-referrer-when-downgrade
Response Headers
content-length:0
date:Fri, 25 Aug 2017 06:50:47 GMT
location:https://urladdress:portnumber2/account/login?.......
server:......
status:302
x-powered-by:ASP.NET
Request Headers
:authority:urladdress:portnumber2
:method:GET
:path:/connect/authorize?......
:scheme:https
accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding:gzip, deflate, br
accept-language:en-US,en;q=0.8
cookie:.AspNetCore.......
upgrade-insecure-requests:1
user-agent:..........
and the message exchange in loadrunner looks the same with the only difference of not including the portnumber2 after the end of the return_uri property.
That results in being redirected to an error page instead of the second redirection.
The script we are using is shown below:
web_set_sockets_option("SSL_VERSION", "TLS1.2");
web_cleanup_cookies();
web_cache_cleanup();
web_add_auto_header("Accept-Encoding","gzip, deflate, br");
web_add_auto_header("Accept-Language","en-US,en;q=0.8");
web_add_auto_header("Accept","text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8");
web_add_auto_header("Upgrade-Insecure-Requests","1");
web_add_auto_header("User-Agent","Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.101 Safari/537.36");
web_set_option("MaxRedirectionDepth","0",LAST);
web_set_max_html_param_len("10000000");
web_reg_save_param_ex("ParamName=url1",
"LB=Location: ",
"RB=\r\n",
LAST);
web_url("urladdress:portnumber1",
"URL=https://urladdress:portnumber1",
"Resource=0",
"RecContentType=text/html",
"Referer=",
"Mode=HTTP",
LAST);
lr_message("redirected address 1 = %s " ,lr_eval_string("{url1}"));
web_reg_save_param_ex("ParamName=url2",
"LB=Location: ",
"RB=\r\n",
LAST);
web_url("connect",
"URL={url1}",
"Resource=0",
"RecContentType=text/html",
"Referer=https://urladdress:portnumber1",
"Mode=HTTP",
LAST);
return 0;
I need to know why the port number on a url is not fetched by the http response message( perhaps there is a configuration I need to create).
Any other comments that might help would be much appreciated.
Have you considered that having a double redirection, particularly ones which are temporary, are going to extract a large performance hit. You have two double handshakes in a row. This is bad magic, independent of the testing tool being used. It is poor architecture on the part of your designers/developers. Cite the defect - Go for a max redirect level of one.
I'm trying to make a static files to be cached in the browser for a small amount of time (10 sec). It seems to be working properly when refreshing page.
- 200 if you are new
- 200 served from cache if you soft-refresh during the first 10 sec
- 304 if you come after more than 10 seconds.
Whenever I add the Http header 'Vary': 'Accept-Encoding' it stops working, meaning that browser cache does not work any more (I always hit the server). This happens because the Http request stop sending if-modified-since or if-none-match whenever I add the Http header 'Vary'.
Are cache-control and vary compatible working together?
I leave the Http Request and Response in case someone can suggest some solution:
Request Header
accept:*/*
accept-encoding:gzip, deflate, sdch
accept-language:en-US,en;q=0.8
cache-control:max-age=0
cookie:XXXXX
referer:XXXXXXXXX
user-agent:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2623.75 Safari/537.36
Response Header
cache-control:max-age=10
content-encoding:gzip
content-type:application/javascript
date:Wed, 13 Apr 2016 12:34:57 GMT
etag:W/"XXXXXXXXXXXXXX"
last-modified:Wed, 13 Apr 2016 12:34:25 GMT
server:nginx/1.9.14
status:200
vary:Accept-Encoding
x-powered-by:Express
In Express I have this configuration to set response headers for static files:
var setHeaders = function(res, path)
{
res.setHeader('Cache-Control', 'max-age=10');
res.vary('Accept-Encoding');
};
app.use('/static', express.static('./app/static', {setHeaders: setHeaders}));
I had a self certificate issue. It seems that it was causing the issue. Without the header vary everything seems to be working properly even if the certificate was not installed. Despite of that, when using the vary header issues were showing up for the cache.
Installing the self certificate made it work.
Solution came from: Why browser does not send "If-None-Match" header?
I am developing an iOS application utilizing the Ionic framework with Cordova and have run into a bit of a snag in my dev cycle. While running on my local dev web server, any RESTful call happening from the $http service is failing with a 401 Not Authorized error even though I am passing the Authorization header. Interestingly enough, the call works fine once I build the app and deploy onto the iOS Emulator.
FWIW, the api calls are to an Atlassian Confluence api.
CORS doesn't seem to be the issue as that has been configured, tested and working on non-authenticated calls.
Here is the very basic call that is failing within the browser but working on the emulator when using the same headers:
$http.defaults.headers.common['Accept'] = 'application/json';
$http.defaults.headers.common.Authorization = 'Basic xxxxxxxxxxxxxx';
$http.get('https://www.example.com/rest/prototype/1/search/site?type=blogpost&spaceKey=TESTSPACE&os_authType=basic')
.success(function (data, status) {
this.serviceData = data;
})
.error(function (data, status) {
console.log(status, data.result);
});
I am sending two custom headers: Accept: application/json and Authorization: Basic *** If I run the application in Chrome with the above service configuration, I see the following Request Headers. There is an added Access-Control-Request-Headers that mentions the Accept and Authorization headers, but those headers are not there. I see the following Request Headers going across the wire:
Accept:*/*
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Access-Control-Request-Headers:accept, authorization <!---- This is added but there is no Authorization Header
Access-Control-Request-Method:GET
Cache-Control:no-cache
Connection:keep-alive
Host:www.example.com
Origin:https://local.example-client.com
Pragma:no-cache
Referer:https://local.example-client.com/
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36
If I make the same call with the Authorization Header using the Advanced Rest Client Chrome extension, it works correctly.
Accept:application/json <!----------- This one is */* when called from $http
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8,nl;q=0.6
Authorization:Basic *** REMOVED *** <!----------- This one is missing when called from $http
Cache-Control:no-cache
Connection:keep-alive
Cookie: *** REMOVED ***
Host:www.example.com
Pragma:no-cache
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.94 Safari/537.36
One thing to note is that if I remove the Authorization header line (below), then the Accept header now appears:
//$http.defaults.headers.common.Authorization = 'Basic ************************';
Can anyone provide me any insight on what I may be missing here?
It's probably a problem with your CORS configuration. Authenticated requests require very specific configuration to work properly with CORS.
Make sure you're
Returning the Access-Control-Allow-Headers header to allow those headers
Returning the exact origin in Access-Control-Allow-Origin (not "*")
Setting withCredentials to true on the XHR (in Angular this can be set in the defaults just like the headers)
(I'm not entirely sure if the "Authorization" header is considered a "credential" if you set it by hand so the last two may or may not be required.)
The reason it works under Cordova is because Cordova doesn't implement origin restrictions for XHRs (they would be a bit pointless since your app doesn't have anything "local" to communicate with)
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.
I have a codeigniter webapp being accessed through https.
Everything works as expected in Firefox, Safari, Chrome and Opera. When using Internet Explorer (V11), about half the time, I get a page saying:
This page can’t be displayed
•Make sure the web address https://... is correct
...
When I look at the Developer Tools (F12), I see that the last request has Result (Aborted)
Localhost:
URL/test.php Result / (Aborted) ......... Initiator / navigate
URL/test.php Result / 200 ......... Initiator / click
sometimes the first request succeeds (200) and the second line doesn't appear
Internet Host:
URL/test.php Result / (Aborted) ......... Initiator / navigate
I never get the Initiator/click line when connecting to this host.
If I hit enter in the browser bar (initiator/navigate), I get result (Aborted) every second time.
If I repeat (press enter in the address bar again) it succeeds/fails/succeeds
However if I click reload or press F5 (initiator/refresh) it works every time.
If I leave a couple of minutes between requests (of whatever kind) it also works every time
I thought this had something to do with the cache. I tried to add extra headers
Pragma:no-cache
Cache-Control: no-cache, must-revalidate
Expires: Mon, 26 Jul 1997 05:00:00 GMT
It seems the hosted server setup has some kind of default configuration that excludes my Pragma/Cache-Control/Expires lines, as these do not appear in the response headers when the pages are served from the internet, but do from localhost
IE is reporting a different User-Agent String when connecting to my hosted server on the internet compared to localhost
Localhost:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.3; WOW64; Trident/7.0; .NET4.0E;
.NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729;
AskTbFXTV5/5.9.1.14019)
Internet:
Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Any clues greatly appreciated
TIA.
I finally had the idea of clearing the browsing history.
This happened by coincidence as I was working on some .css changes at the time and those changes didn't seem to get reflected when reloading the page.
I cleared Temporary Internet files, Cookies and History. I assume clearing Temporary Internet files is what cured the problem.