Http Request not reaching the IIS module - asp.net

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

Related

Go-reverseproxy interferes with .net [Authorize] attribute

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.

Serving Partial HTTP Response

I would like to make a file download resumable using byte-range requests.
The problem is that my existing download action is responding on a POST method and I would like to keep it that way.
But it seems from my early tests that Chrome turns interrupted POST requests for file downloads into GET requests when the user tries to resume and thus the resuming of the download fails.
Am I missing something?
Is this something related to the HTTP specs that only allow GET requests to be resumed?
Or is it simply a design flaw in Chrome (and maybe other browsers as well) that makes it forget the original HTTP method used?
UPDATE:
Here are the request/response data:
Initial POST request:
POST http://localhost:35547/Download?Guid=396b4697-e275-4396-818c-548bf8c0a281 HTTP/1.1
Host: localhost:35547
Connection: keep-alive
Content-Length: 0
Cache-Control: max-age=0
Origin: http://localhost:35547
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Referer: http://localhost:35547/File/396b4697-e275-4396-818c-548bf8c0a281
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.8
Cookie: __RequestVerificationToken=LuPgM05MHrsuyskgfhsrHVUs; ASP.NET_SessionId=gfiulghfuygisghkf; .ASPXAUTH=FGDJHGDHSDFB15AFDE6371CGJHDFGFBHD; fileDownload=true
Initial response (to the request above):
HTTP/1.1 200 OK
Cache-Control: private, s-maxage=0
Content-Type: application/zip
Server: Microsoft-IIS/7.5
X-AspNetMvc-Version: 5.2
Content-Disposition: attachment; filename="FILE-396b4697e2754396818c548bf8c0a281.zip"
X-AspNet-Version: 4.0.30319
Set-Cookie: fileDownload=true; path=/
X-Powered-By: ASP.NET
Date: Wed, 09 Nov 2016 11:13:50 GMT
Content-Length: 1885473
PK.......... ZIP file data .............................................
After the interruption, this is the request that the browser does on resume (notice the GET method used):
GET http://localhost:35547/Download?Guid=396b4697-e275-4396-818c-548bf8c0a281 HTTP/1.1
Host: localhost:35547
Connection: keep-alive
Referer: http://localhost:35547/File/396b4697-e275-4396-818c-548bf8c0a281
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36
Accept-Encoding: gzip, deflate, sdch, br
Accept-Language: en-US,en;q=0.8
Cookie: __RequestVerificationToken=.............
(Some data from security-related cookies have been shortened and altered)
Am I missing something ?
It depends, upon how have you analyzed the behavior of google chrome. Ideal way will be use any proxy or to use packet sniffer such as Wireshark to see what request method, is used by chrome in subsequent request.
Is this something related to the HTTP specs that only allow GET
requests to be resumed?
As of now, there's no mention in spec of HTTP protocol, that only GET requests can be resumed.
Or is it simply a design flaw in Chrome (and maybe other browsers as
well) that makes it forget the original HTTP method used?
Yes, It's the flaw of google chrome. Make sure that you check it on the latest version of Google chrome with all the update patches. Also check it on other browsers.
For more info about HTTP protocol, refer to https://www.ietf.org/rfc/rfc2616.txt.
Refer to following request, for serving partial response : https://en.wikipedia.org/wiki/Byte_serving
Edit
For more updated info regarding HTTP info, refer to :-
https://www.rfc-editor.org/rfc/rfc7230

302 Redirect Originates from ASP.NET or IIS

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

IIS6 Compression only working over HTTPS

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"

Can't find the correct header for a request on Windows server

I made an HTML page with some JavaScript that works fine on my laptop on Linux, but fails when I upload it on a Windows server. I think it is a header issue so I am not writing the Ajax code, but the request headers :
Ajax Request :
GET /index-1.html HTTP/1.1
Host: mydomain.com
Connection: keep-alive
Accept: undefined
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1553.0 Safari/537.36 SUSE/30.0.1553.0
Referer: http://mydomain.com/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Server Answer :
HTTP/1.1 406 Not Acceptable
Content-Type: text/html
Server: Microsoft-IIS/7.0
X-Powered-By: ASP.NET
Date: Thu, 19 Sep 2013 19:40:44 GMT
Content-Length: 1346
What should I set the headers to?
If you actually read the description of status code 406 you'll quickly find out that the problem is likely caused by "accept: undefined".

Resources