We have recently enabled compression in IIS6 for our ASP.NET applications (some 2.0 some 4.0) and have found that GZip is only being performed when the request is made over HTTPS.
This problem is being seen on all servers in our web farm. I have also checked that the same problem exists regardless of the browser used.
I've searched for over an hour and can't find anything on this, so hoping someone may be able to help. Examples follow
HTTP Request:
GET /about.htm HTTP/1.1
Host: www.website.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36
Referer: http://www.google.co.uk
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
HTTP Response (not GZipping):
HTTP/1.1 200 OK
Cache-Control: private
Content-Length: 65568
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Thu, 26 Sep 2013 09:26:46 GMT
HTTPS Request:
GET /about.htm HTTP/1.1
Host: www.website.com
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.76 Safari/537.36
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
HTTPS Response (GZip working):
HTTP/1.1 200 OK
Cache-Control: private
Date: Thu, 26 Sep 2013 09:29:39 GMT
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
UPDATE
I've run a request trace in IIS - the offending requests have the following line
IISCompression DYNAMIC_COMPRESSION_NOT_SUCCESS "NO_MATCHING_SCHEME"
Related
I am running an ASP.NET MVC web application with Vue.js as frontend. For access control management, I am using pritunl-zero, a zero-trust reverse-proxy written in Go.
Locally the app works fine with anonymous authentication but deployed and protected from the proxy every method call that need auth will be denied with 401.0 from the IIS10 web server.
When I remove the proxy from the infrastructure it works.
Protected method call (eg)
[Authorize]
[HttpPut, Route("api/ping"), ResponseType(typeof(WorkflowDto))]
public IHttpActionResult PingWorkflow(WorkflowCommentDto commentDto)
Vue frontend log in console
createError.js:16
Uncaught (in promise) Error: Request failed with status code 401
at e.exports (createError.js:16:15)
at e.exports (settle.js:17:12)
at XMLHttpRequest.O (xhr.js:66:7)
The HTTP-header causing 401 response
GET /api/workflow/ping HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: de,de-DE;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6,cy;q=0.5
Cache-Control: no-cache
Connection: keep-alive
Cookie: pritunl-zero=MTY1NzY5OTc0NHxEdEU...
Host: workflow.host.de
Pragma: no-cache
Referer: https://workflow.host.de/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36 Edg/103.0.1264.49
sec-ch-ua: ".Not/A)Brand";v="99", "Microsoft Edge";v="103", "Chromium";v="103"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
token: 8cf78dcd-3b17-4481-8be3-10821519c23c
The working HTTP-header
:authority: wf.host.de
:method: GET
:path: /api/workflow/Ping
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: de,de-DE;q=0.9,en;q=0.8,en-GB;q=0.7,en-US;q=0.6,cy;q=0.5
cache-control: no-cache
cookie: pritunl-zero=MTY1Nzc3NjkwOHxZTVRUWUF5d0s0c180aTB...; pritunl-zero=MTY1NzgwMTE3MnxlWk9vYkZ2ZGQ0TTdVZmZKODdWb19SRzFSV...
pragma: no-cache
referer: https://wf.host.de/
sec-ch-ua: ".Not/A)Brand";v="99", "Microsoft Edge";v="103", "Chromium";v="103"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
sec-fetch-dest: empty
sec-fetch-mode: cors
sec-fetch-site: same-origin
token: 8cf78dcd-3b17-4481-8be3-10821519c23c
user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/103.0.5060.114 Safari/537.36 Edg/103.0.1264.49
The response from server (that one works)
cache-control: no-cache
content-length: 214
content-type: application/json; charset=utf-8
date: Thu, 14 Jul 2022 12:25:09 GMT
expires: -1
pragma: no-cache
server: Microsoft-IIS/10.0
strict-transport-security: max-age=0; includeSubDomains; preload
x-aspnet-version: 4.0.30319
x-powered-by: ASP.NET
Response from server (401)
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache
Content-Length: 61
Content-Type: application/json; charset=utf-8
Date: Wed, 13 Jul 2022 08:09:12 GMT
Expires: -1
Pragma: no-cache
Server: Microsoft-IIS/10.0
X-Aspnet-Version: 4.0.30319
X-Powered-By: ASP.NET
Has anyone any hint how to fix this, that the application can work with the proxy?
What I tried:
New IIS with new site and new deployment
Many web.config settings regarding anonymous authentication
Different configs regarding the application pool
Latest update from pritunl
Thanks in advance for any hint.
The Situation
Every time I click the home button below I find thaty it takes me to 404 not found as below that:
Wordpress dashboard
Error
I am not sure why this is occuring, but it seems to be redirecting to away from the port:8080 but I have set the wp_options site_url and home_url to http://localhost:8080/wordpress within phpAdmin. How could I fix this?
======
EDIT:
The behavior when looking in the log in the console after clicking the home button is:
Request URL: http://localhost:8080/wordpress/
Request Method: GET
Status Code: 301 Moved Permanently (from disk cache)
Remote Address: [::1]:8080
Referrer Policy: strict-origin-when-cross-origin
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Wed, 03 Feb 2021 17:40:28 GMT
Location: http://localhost/wordpress/
Server: Apache/2.4.46 (Win64) OpenSSL/1.1.1h PHP/7.4.13
X-Powered-By: PHP/7.4.13
X-Redirect-By: WordPress
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-ES,en-US;q=0.9,en;q=0.8
Connection: keep-alive
Cookie: wp-settings-1=mfold%3Do; wp-settings-time-1=1612439758; wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_7d02bf5d4e081af2908123233e7fb2e7=Kwsswart%7C1612681149%7C3lzaDUQayIVeJSHGTZiiOEF0IPOnAvdyMTTlSq6SP7Z%7C66c2a42cd2b27d342bd5a234fb1276e73122a06eb9761a76f336f26c5cea485e
Host: localhost
Referer: http://localhost:8080/
sec-ch-ua: "Chromium";v="88", "Google Chrome";v="88", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.104 Safari/537.36
Followed by:
Request URL: http://localhost/wordpress/
Request Method: GET
Status Code: 404 Not Found
Remote Address: [::1]:80
Referrer Policy: strict-origin-when-cross-origin
Connection: Keep-Alive
Content-Length: 196
Content-Type: text/html; charset=iso-8859-1
Date: Fri, 05 Feb 2021 06:59:33 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.46 (Win64) PHP/7.4.13
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-ES,en-US;q=0.9,en;q=0.8
Connection: keep-alive
Cookie: wp-settings-1=mfold%3Do; wp-settings-time-1=1612439758; wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_7d02bf5d4e081af2908123233e7fb2e7=Kwsswart%7C1612681149%7C3lzaDUQayIVeJSHGTZiiOEF0IPOnAvdyMTTlSq6SP7Z%7C66c2a42cd2b27d342bd5a234fb1276e73122a06eb9761a76f336f26c5cea485e
Host: localhost
Referer: http://localhost:8080/
sec-ch-ua: "Chromium";v="88", "Google Chrome";v="88", ";Not A Brand";v="99"
sec-ch-ua-mobile: ?0
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-site
Sec-Fetch-User: ?1
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like
wp_admin settings
You still have to call your frontend under port 8080
localhost:8080/wordpress
EDIT:
Have a look here: themeisle.com/blog/install-xampp-and-wordpress-locally
Is it possible to work out whether a redirect occurred from something setup within IIS, or whether an ASP.NET application issued the redirect for IIS to perform?
I have an ASP.NET site which is redirecting a HTTPS page to HTTP page (which I don't want it do do), and which I have confirmed by the following headers:
https://***.co.uk/MainWebsite/Intro.aspx
GET /MainWebsite/Intro.aspx HTTP/1.1
Host: ***.co.uk
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
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, br
Cookie: _ga=GA1.3.1422039573.1457307455; ASP.NET_SessionId=bazsdsfsdfrre0vp30joy
Connection: keep-alive
Upgrade-Insecure-Requests: 1
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: http://***.co.uk/MainWebsite/Intro.aspx
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Thu, 22 Sep 2016 08:04:13 GMT
Content-Length: 184
Do the "X-AspNet-Version" and "X-Powered-By" headers suggest that ASP.NET have told IIS to do a redirect, or is it impossible to tell from this information?
Thanks
I've made a simple client socket in c that has been mostly successful.
The problem I'm having is my client socket receives a 301 status from, ironically, www.w3.org.
Observe, when I send the following GET with my client c socket
GET / HTTP/1.1
Host: time.com
Connection: keep-alive
Accept: */*
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
I receive
HTTP/1.1 200 OK
Server: nginx
Date: Thu, 12 Nov 2015 08:44:34 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Last-Modified: Thu, 12 Nov 2015 08:40:48 GMT
Cache-Control: max-age=74, must-revalidate
X-nananana: Batcache
Vary: Cookie
X-hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.
X-Pingback: http://time.com/xmlrpc.php
X-UA-Compatible: IE=edge,chrome=1
Link: <http://ti.me/nACNOw>; rel=shortlink
Content-Encoding: gzip
X-ac: 4.ord _dca
However, when I send a GET request to www.w3.org.
GET / HTTP/1.1
Host: www.w3.org
Connection: keep-alive
Accept: */*
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.80 Safari/537.36
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
I receive
HTTP/1.1 301 Moved Permanently
Content-length: 0
Location: http://www.w3.org/
Connection: close
When google chrome sends a similar GET to www.w3.org
GET / HTTP/1.1
Host: www.w3.org
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.86 Safari/537.36
The server responds with
HTTP/1.1 200 OK
Accept-Ranges: bytes
Cache-Control: max-age=600
Content-Length: 39276
Content-Location: Home.html
Content-Type: text/html; charset=utf-8
Date: Sun, 15 Nov 2015 04:40:47 GMT
ETag: "996c-524790d293380;89-3f26bd17a2f00"
Expires: Sun, 15 Nov 2015 04:50:47 GMT
Last-Modified: Sat, 14 Nov 2015 05:00:14 GMT
P3P: policyref="http://www.w3.org/2014/08/p3p.xml"
Server: Apache/2
TCN: choice
Vary: negotiate,accept
Why does my client's GET receive a 301 despite its near equivalence with Chrome's GET?
Do some websites have a strict set of required HTTP header fields?
Is there a bigger picture that I'm missing?
w3.org enforces the canonical URL www.w3.org with a permanent redirect. Requesting just w3.org will result in a HTTP 301. The canonical URL is a matter of preference so it shouldn't be assumed that the non-prefixed URL will always redirect to the www prefixed one.
During development of an IIS module for basic authentication, I stocked to a problem. The module is working fine when browsing the pages, but when calling web-services it seems that request does not reach the module and some in-the-middle module takes control of request.
using fiddler, I found out when Content-type in http request header is set to application/json that in the middle module/handler is triggered. so following request does not work:
when working fine, the server should ask client to send the user credentials by setting the WWW-Authenticate header in response
GET /WebServices/service.asmx/someMethod?param=test HTTP/1.1
Host: localhost
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.152 Safari/537.22
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Content-Type: application/json
asdfasdf
asdfasdfasdf
response: notice the jsonerror header in response
HTTP/1.1 401 Unauthorized
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/7.5
jsonerror: true
X-Powered-By: ASP.NET
Date: Mon, 11 Mar 2013 23:49:02 GMT
Content-Length: 105
{"Message":"Authentication failed.","StackTrace":null,"ExceptionType":"System.In
validOperationException"}
where this one works fine: notice that there is no content-type
GET /WebServices/service.asmx/someMethod?param=test HTTP/1.1
Host: localhost
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.152 Safari/537.22
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
asdfasdf
asdfasdfasdf
and the correct response is: notice the WWW-Authenticate header in response
HTTP/1.1 401 Unauthorized
Location: http://localhost/WebServices/service.asmx/someMethod?param=test
Server: Microsoft-IIS/7.5
WWW-Authenticate: Basic
X-Powered-By: ASP.NET
Date: Mon, 11 Mar 2013 23:59:48 GMT
Content-Length: 0
Well, that in-the-middle module was ScriptModule where we had both 3.5 and 4.0 version being added in the config. inspecting them through dotpeek, I found that the script module checks request's content-type against being application/json and then tries to handle the request as a REST request or webservice call.
By removing them, nothing special happened. I assume that they are to be used when script manager or Microsoft Specific AJAX services are used. You can find more about it in
ASP.Net Ajax Programming Tricks