I have an Spring application (with Spring Security and Spring MVC) deployed in a Tomcat server. The application works perfecty in Firefox, Chrome, Opera and IE9.
I have a weird problem with IE8. The login screen loads, and (as I can see in server logs) the session is open when username and password are provided. Once the user is logged, and the browser is redirected to the main page, a 404 error is returned by the server.
As IE8 developer tools doesn't have a net panel, I have used Fiddler to monitor http connections. I thought that it could be happening that it was doing a wrong request during page loading but it was the main page request wich is responsing with 404.
How is it possible that the server responses with 404 to the main page request just only in IE8?
Thank you.
Edited:
Those are the request header for IE8 and Firefox respectively:
GET /myWebApp/ HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: es-ES
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Tablet PC 2.0; .NET4.0C; .NET4.0E)
UA-CPU: AMD64
Accept-Encoding: gzip, deflate
Host: dev.mydomain.com
Connection: Keep-Alive
Cookie: JSESSIONID=ABA1382304002F894ABDFCC2442FA5F8; SPRING_SECURITY_REMEMBER_ME_COOKIE=NGUxMTZlOTY3OGM0OTgxNDY4NDczOTlkOjEzMjQ1ODMwMzU0MDI6OWZiYzdhYjY1ODY2Mzc3YmI0Yzc5YTMzMWI5NDhjNTg
--
GET /myWebApp/ HTTP/1.1
Host: dev.mydomain.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: es-es,chrome://global/locale/intl.properties;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Cookie: JSESSIONID=7FD3B02252E2FCBC9BE7249AFD84F541; SPRING_SECURITY_REMEMBER_ME_COOKIE=NGUxMmYxMTgzMmRjZTM0NzYyMWVjOWEwOjEzMjQ1ODMwMTA1MTU6MzFiYzU4OGQ4NTMwN2Y3M2I4YmQzN2M0NzY2MzcwZjI
Knowing that the problem was about "Accept" I have revised the MVC Controller classes mappings and I have finaly found the issue. Somehow this was the way that the main page was mapped in MVC so it didn't work whith the IE8 header attribute:
#RequestMapping( value = "/", headers = "Accept=text/*" )
I have learned a hard lesson today. ;-)
Related
I've created a self hosted Web API (Web API 2.2 + Owin). The service is quite simple and only returns the list of GPIO pin values.
On my Pi itself, it works perfectly. I can call the service without problems. Only when I try to call it from my PC a HTTP 400 is returned:
Request:
GET http://192.168.178.105/RobotApi/GetGpioPinValues HTTP/1.1
Host: 192.168.178.105
Connection: keep-alive
Accept: application/json, text/plain, */*
Origin: http://localhost
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Referer: http://localhost/piRobot.WebSite/index.html
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8,de-DE;q=0.6,de;q=0.4
Response:
HTTP/1.1 400 Bad Request
Content-Type: text/html; charset=utf-8
Server: Mono-HTTPAPI/1.0
Date: Fri, 02 Jan 2015 16:19:24 GMT
Content-Length: 35
Connection: close
<h1>Bad Request (Invalid host)</h1>
I hope someone out there can help me. Any suggestions?
Thanks a lot,
Dante
Ok. Got it:-)
It was no problem with raspberry or mono or Web Api itself. The self hosted service was initialized with the base URL http://localhost. The strange thing is, the service is only available via localhost, but not via the according IP address!!!
So what I've done now is, I substituted localhost with the IP address of my Pi and it works perfectly. Now the service is only accessible via the IP?!
I still have no clue why it makes a difference, but obviously it does.
Following on closely from this question SSRS IE8 JavaScript Error Invalid Character ScriptResource.axd I have done some debugging and narrowed the issue down to a gzip, deflate problem.
We have various machines with IE8 installed on them. The problem is, some installations of IE don't seem to add the Accept-Encoding: gzip, deflate to the HTTP Request header when requesting a JavaScript resource via ScriptResource.axd.
Here is the HTTP request off machine 1 (works fine):
GET http://10.x.x.x6/Reports_2/ScriptResource.axd?d=dz2_T_-skCIGFrM350LrrgpIbuyQ3hv0Po2nyTqnjMC_h2orbb8AW34-wlapNOlKQn3w_65Hv8xicNrMgbLAWsuKLkB24a0JnVTM3AD64R_ELK1K6KpCKGgYkO_evQ1uY6IeQkuEpQDrHclftKpS0G8rnJM1&t=4d63fd9d HTTP/1.1
Accept: text/html, application/xhtml+xml, */*
Accept-Language: en-GB
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)
Accept-Encoding: gzip, deflate
Proxy-Connection: Keep-Alive
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAJIAAAAYABgAqgAAABgAGABYAAAAEAAQAHAAAAASABIAgAAAABAAEADCAAAAFYKI4gYBsR0AAAAP5M9BpXhDtQyLRxQO0MslBkQARQBOAEIASQBHAEgAUwBIAEkAUgBFAGEAbAB5ADgANgA3ADcANwBEAEMAQwAwADEAOQA4ADgAOAAW1o72sWx0hAAAAAAAAAAAAAAAAAAAAAD8+dJyp0KpjG5sP9WUlmrk4FptdhpYQAEETsImSmR+ZzMapF8Z91Wv
Host: 10.x.x.x6
And here is the same request made off machine 2 (doesn't work as its returning gzipped data):
GET http://10.x.x.x6/Reports_2/ScriptResource.axd?d=dz2_T_-skCIGFrM350LrrgpIbuyQ3hv0Po2nyTqnjMC_h2orbb8AW34-wlapNOlKQn3w_65Hv8xicNrMgbLAWsuKLkB24a0JnVTM3AD64R_ELK1K6KpCKGgYkO_evQ1uY6IeQkuEpQDrHclftKpS0G8rnJM1&t=4d63fd9d HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/x-ms-application, application/x-ms-xbap, application/vnd.ms-xpsdocument, application/xaml+xml, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-gb
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E; BRI/2)
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAIIAAAAYABgAmgAAABgAGABIAAAAEAAQAGAAAAASABIAcAAAAAAAAACyAAAABYKIogUBKAoAAAAPRABFAE4AQgBJAEcASABTAEgASQBSAEUAagBvAG4AOQA0ADYAMQA0AEQAQwBDADAAMQAzADUANgA2APyGLo3yOcCnAAAAAAAAAAAAAAAAAAAAABccpJT8TohKqbhq3PzWDPApr1NmEypAPg==
Connection: Keep-Alive
Pragma: no-cache
Host: 10.x.x.x6
The problem seems to be that IE is not-requesting gzipped data, but its actually getting gzipped data from the server (an then its failing because it doesn't think its gzipped).
If i manually decompress the data returned using zcat or something, i can view the returned JavaScript fine.
What would cause IE8 not to add this header onto the request ??
I've got a routine that queries galfind and for most situations it returns the expected XML response after issuing a basic GET. I'm trying it out now on an older (Exchange 2003) server and the galfind GET will only return the HTML search form. The query response data returns correctly along with the form content but it'd be nice to get it in XML format. So two related questions:
Does OWA in Exchange 2003 support XML responses for galfind?
If so, how does one either modify the HTTP request or configure the server to retrieve the XML formatted response from a galfind query?
Here's an example GET request I've been playing with:
GET
http://mail.mydomain.com/exchange/administrator#mydomain.com/?cmd=galfind&dn=C
HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
Accept: text/xml
Authorization: Basic
Host: mail.mydomain.com
Adding "MSIE 6.0" to the User-Agent seems to allow you to toggle over to an XML formatted response, e.g.
GET
http://mail.mydomain.com/exchange/administrator#mydomain.com/?cmd=galfind&dn=C
HTTP/1.1 User-Agent: Mozilla/5.0 (MSIE 6.0; Windows NT 6.1; WOW64; rv:8.0.1)
Gecko/20100101 Firefox/8.0.1
Accept: text/xml
Authorization: Basic
Host: mail.mydomain.com
I have MVC application that return PDF file.
public FileStreamResult GetDocument(int id)
{
return File(stream, "application/octet-stream", documentsModel.Name);
}
I have two test server. One is private and another is public.
From private I can download document and I get:
GET /Documents/GetDocument/3576 HTTP/1.1
Accept: */*
Accept-Language: en-GB
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; BRI/2)
Accept-Encoding: gzip, deflate
Host: appserver
Connection: Keep-Alive
Cookie: ASP.NET_SessionId=vgzn4qkelxdmic3nbaqftsxd; .FidesAuthCookie=BF08E0DCAAA54D7D78AB6BD30D5ECA523C045F9B401B10693B6CE57D7D4C677C0908E24D92511DC75A487D6CAE6DD780AA8B4419A5A5D9258A4985AF6870D3AD1A0B3C01B8A620A1E14FEDDE298CCE255AE4B4C2F76D2635B8C5DF332AF19AAB; dynatree-active=3576; dynatree-focus=; dynatree-expand=496%2C603%2Cfolder_622; dynatree-select=
HTTP/1.1 200 OK
**Cache-Control: private, s-maxage=0**
Content-Type: application/octet-stream
Server: Microsoft-IIS/7.5
Set-Cookie: .FidesAuthCookie=BF08E0DCAAA54D7D78AB6BD30D5ECA523C045F9B401B10693B6CE57D7D4C677C0908E24D92511DC75A487D6CAE6DD780AA8B4419A5A5D9258A4985AF6870D3AD1A0B3C01B8A620A1E14FEDDE298CCE255AE4B4C2F76D2635B8C5DF332AF19AAB; expires=Fri, 13-Apr-2012 13:31:05 GMT; path=/
X-AspNetMvc-Version: 3.0
Content-Disposition: attachment; filename=test.pdf
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 13 Apr 2012 13:01:04 GMT
Content-Length: 49613
From my public server I get
GET /Documents/GetDocument/97 HTTP/1.1
Accept: */*
Accept-Language: en-GB
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E; BRI/2)
Accept-Encoding: gzip, deflate
Host: beta.qi-care.nl
Connection: Keep-Alive
Cookie: ASP.NET_SessionId=h3utp0bfu4zwhqysntame3we; dynatree-active=97; dynatree-focus=; dynatree-expand=4%2Cfolder_10; dynatree-select=; .FidesAuthCookie=F0DED3D98BF4115C910B0A29EC2C809902B49F15518952DFA78DDB4358B5F0C1A9EDAFB50DD0CA761B433ED68034C2539ABCCDA0C50FF5EEEE3573D3C77E550416CDB24B302C9EB831AC597040E6D255E9B582E8A29D5FC03454F2A0742ECC9DEC61070091F9A66D1C3FC7F9CA10C1B8BB9B5109CB613C98AEE32AFE5A0F8A28
HTTP/1.1 200 OK
**Cache-Control: private, no-cache="Set-Cookie", s-maxage=0**
Content-Type: application/octet-stream
Server: Microsoft-IIS/7.5
Set-Cookie: .FidesAuthCookie=F0DED3D98BF4115C910B0A29EC2C809902B49F15518952DFA78DDB4358B5F0C1A9EDAFB50DD0CA761B433ED68034C2539ABCCDA0C50FF5EEEE3573D3C77E550416CDB24B302C9EB831AC597040E6D255E9B582E8A29D5FC03454F2A0742ECC9DEC61070091F9A66D1C3FC7F9CA10C1B8BB9B5109CB613C98AEE32AFE5A0F8A28; expires=Fri, 13-Apr-2012 13:19:35 GMT; path=/
X-AspNetMvc-Version: 3.0
Content-Disposition: attachment; filename=test.pdf
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 13 Apr 2012 12:49:35 GMT
Content-Length: 49613
and I get error
http://support.microsoft.com/kb/323308
For some reason, I have from these two server, two different responses. But I found on Microsoft support that client should change registry
To resolve this issue in Internet Explorer 7 and in Internet Explorer 8, follow these steps:
Start Registry Editor.
For a per-user setting, locate the following registry key:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
For a per-computer setting, locate the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings
On the Edit menu, click Add Value.
To override the directive for HTTPS connections, add the following registry value:
"BypassSSLNoCacheCheck"=Dword:00000001
To override the directive for HTTP connections, add the following registry value:
"BypassHTTPNoCacheCheck"=Dword:00000001
Quit Registry Editor.
Microsoft
We faced this problem at work, it turned out to be a bug in Internet Explorer (in our case IE8-), that gives an error when trying to download a file in SSL (Are you in https, right?). The problem is that if the server sends to the browser an http header that disables caching, Explorer gives an error. In your case, maxage=0 is equivalent to Cache-Control: no cache.
The solution server side is that you should overwrite this header to tell IE8 to cache the response, with Cache-Control: private for example.
Be careful that some application servers (such as in our case Websphere Application Server) append automatically no-cache="Set-Cookie" when a cookie is set.
Finally, there is another solution, if applicable, that solves the problem, but it should be applied client-side on the browser:
look at Method 1:
http://support.microsoft.com/kb/2549423
I have a virtual directory on IIS 5.1 with two aspx pages. Access to Page1 configured as "Integrated Windows Authentication" option turned on and anonymous access is disabled. Page2 available through anonymous access. On client side there is XmlHttpRequest object that can send requests that contains POST data to this pages.
At first I try to send request to Page1. Standard Windows Authentication dialog appears, I entering my credentials and Page1 succesfully receiving POST data.
After that I try to make the same POST request to Page2 that can be accessed anonymously. And in this case Request has header Content-Length=0, and no any data has been sended.
If to repeat request to Page1 - it successfully receiving POST data. The same code is working good in Firefox 3.5. Page2 can receive data even after sending request to Windows Authentication required Page1. What can be wrong? And maybe it is any workaround for this problem?
Thanks!
Sending data:
function sendRequest() {
var url = "http://tom/AuthTest/Default.aspx";
var data = "data";
reqSend(url, data);
}
function sendRequestToWinAuth() {
var url = "http://tom/AuthTest/DefaultWA.aspx";
var data = "newdata";
reqSend(url, data);
}
function reqSend(url, data) {
var xmlhttp = createRequestObject();
if (!xmlhttp) {
alert("Cannot create XMLHttpRequest object.");
return;
}
try {
xmlhttp.open("POST", url, false);
xmlhttp.send(data);
}
catch (ex) {
alert("Error: " + ex.message);
}
}
Request to Page1:
POST /AuthTest/DefaultWA.aspx HTTP/1.1
Accept: */*
Referer: http://tom/AuthTest/client/testauth.html
Accept-Language: ru
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: tom
Content-Length: 7
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: innovator_user=admin
Authorization: Negotiate TlRMTVNTUAADAAAAGAAYAF4AAAAYABgAdgAAAAoACgBIAAAABgAGAFIAAAAGAAYAWAAAAAAAAACOAAAABYKIogUBKAoAAAAPcwBjAGEAbgBkAHQAbwBtAFQATwBNAGUdQIkWMQ6PAAAAAAAAAAAAAAAAAAAAAAo3goJdI7RH9poJwnjypksH2F2pIzbEOQ==
newdata
Request to Page2:
POST /AuthTest/Default.aspx HTTP/1.1
Accept: */*
Referer: http://tom/AuthTest/client/testauth.html
Accept-Language: ru
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729)
Host: tom
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: innovator_user=admin
Authorization: Negotiate TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==
Content-Length: 0
Seems i have found a way to keep pages requiring windows authentication and pages allowing anonymous access on one site.
There 2 ways to do it:
This behavior (bug) is only reproducing when using NTLM authentication. So to avoid it, we can setup a Kerberos authentication mode on IIS site. Here is a good detailed FAQ about IIS and Kerberos: http://www.adopenstatic.com/faq/
To tell a thruth I have tried to follow the first way, but really my IIS doesn't want to use Kerberos anyway. On other hand I try to check this situation on another machine - and was surprised - Kerberos authentication was used there by default. I have tried to found any difference in configurations - but not successfull. So there is the second way:
Using Windows Authentication mode on a directory or file in a separate directory. For example we have some structure like:
../Default.aspx
../auth/DefaultWinAuth.aspx
../auth/DefaultWinAuth2.aspx
We can set IWA (Integrated Windows Authentication) mode on 'auth' directory or DefaultWinAuth page. After that all files and subdirectories that are included in this folder or situated on the same level as 'DefaultWinAuth.aspx' page will not be able to receive POST data. But all other files and directories outside directory 'auth' will work fine.
I've had this exact problem, apparently its by design in IE, check out this link:
http://www.websina.com/bugzero/kb/browser-ie.html
Basically IE won't send POST data to an unauthenticated URL/page if you are currently on an authenticated URL/page. I didn't find a work-around, I had to do something else, but let me know if you do figure out a way. Cheers