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 ??
Related
I have fetch api call from Vue js code which sends form-data to laravel backend
I am posting request. Please suggest how to parse this using laravel request?
POST /acapp/public/api/createmember HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9,mr-IN;q=0.8,mr;q=0.7,ur-PK;q=0.6,ur;q=0.5,hi-IN;q=0.4,hi;q=0.3
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 142
Content-Type: application/json
Host: localhost
Mimetype: multipart/form-data
Origin: chrome-extension://fhbjgbiflinjbdggehcddcbncdddomop
Postman-Token: cd1ca586-560b-fdf7-3fd6-afe2f457d676
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36
------WebKitFormBoundaryoMWbAbNZyySY3vCB
Content-Disposition: form-data; name="dob"
45345345
------WebKitFormBoundaryoMWbAbNZyySY3vCB--
You don't need to parse the request. The HTTP-Request Stack of Laravel will do it automatically and call your action you defined for that url.
https://laravel.com/docs/5.7/requests
Here is a good example how to get informations from your request. So you don't have to think about that. In the documentation you can find a part how to write VUE components.
https://laravel.com/docs/5.7/frontend
i think that could help you.
I recently tried using gzip compression to improve web UI performance. I configured Tomcat Connector as below.
compression="on"
compressionMinSize="2048"
noCompressionUserAgents="gozilla, traviata"
compressableMimeType="text/html,text/xml,text/css,text/javascript,text/json,application/x-javascript,application/javascript,application/json"
Below is RequestHeader - Accept-Encoding is gzip, deflate.
Key Value
Request GET /app/jquery-ui.min.js HTTP/1.1
Accept */*
Referer https://cdduat.app.com/Apptech/
Accept-Language en-US
User-Agent Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; Trident/7.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; InfoPath.3)
Accept-Encoding gzip, deflate
Host cdduat.app.com
Connection Keep-Alive
Cache-Control no-cache
Cookie JSESSIONID=CB793FFEE9A34B5B8E7DE34A17C90B5D; mbox=session#1436174197635-942865#1436176058|PC#1436174197635-942865.28_07#1437383802; s_fid=498342221B10B4ED-297E46742B9393BE; s_vi=[CS]v1|2ACD23BB851D5DBF-40001903C00C9391[CE]; oo_event_entry=41eebf1007f6e19f5b0ee4b5841be2441e970f9c
For response header - there is no Accept-enconding key value. Moreover I'm not sure if its working or not. Below is Response Header. Web form load time is still the same. Not sure if I am doing anything wrong here.
Server Apache-Coyote/1.1
Accept-Ranges bytes
ETag W/"238326-1435860126000"
Last-Modified Thu, 02 Jul 2015 18:02:06 GMT
Content-Type application/javascript
Content-Length 238326
Date Mon, 13 Jul 2015 22:22:23 GMT
Also I could see Cache-control value as no-cache. Does it mean browser wont cache JS files and request for those resources again on subsequent request?
https://serverfault.com/questions/707207/apache-2-4-tomcat-7-0-57-js-and-css-are-not-getting-gzipped-in-response
I'm using official custom receiver from Github and I'm trying to play MPEG-DASH Widevine protected video stream. Receiver is running on Nexus Player 5.1.1. I'm correctly setting customData and licence server url. The problem is that player (DRM component) is not correctly generating needed data for POST request to the licence server. This data should be generated with data from PSSH box and include information about DRM client and more. Below is the almost empty POST request (omitted some CORS specific headers) with request body containing only two bytes (08 04)
POST XYZ HTTP/1.1
Host: XYZ
Connection: keep-alive
Content-Length: 2
Origin: ABC
User-Agent: Mozilla/5.0 (Linux; Android 5.1.1; Nexus Player Build/LMY47V) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.75 Safari/537.36 CrKey/1.13.31432
content-type: text/xml;charset=utf-8
Accept: */*
Referer: http://ABC/ftp-custom/CastMediaPlayerStreamingDRM/mpl.html
Accept-Encoding: gzip, deflate
Accept-Language: en-GB
CAST-DEVICE-CAPABILITIES: {"display_supported":true}
..
The correct request body (on Windows / Chrome) should look like this (ommited "non-human readable" content within request body)
POST XYZ HTTP/1.1
Host: XYZ
Connection: keep-alive
Content-Length: 1763
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.152 Safari/537.36
Origin: http://shaka-player-demo.appspot.com
Accept: */*
Referer: http://shaka-player-demo.appspot.com/
Accept-Encoding: gzip, deflate
Accept-Language: cs,en;q=0.8
ChromeCDM-Windows-x86
architecture_name x86-32
company_name Google
model_name ChromeCDM
platform_name Windows2
Thank you for any how to make this working correctly.
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 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. ;-)