I have a Windows 2008 Server running the default IIS 7.0. I have an http handler where GET, POST, and PUT are working fine, but whenever I issue a DELETE request, there is nothing coming back from the server at all.
I'm using Fiddler to issue the request (which works great on my development Windows 7 machine). I have disabled WebDav, etc., which by the way should have given me some kind of error response anyway. In this case there's nothing. I've tried to enable tracing on the server and don't see anything there either.
I have tried to issue the DELETE web requests on other pages on the server as well, including non-existing ones, but there's never any respone. Maybe something on the server is "eating" the request before it gets to IIS?
To test this last question, I installed Fiddler on the server itself and posted the DELETE request from within the server. This actually worked!!! So, what's stopping the external request then?
Related
I'm developing a Wordpress theme that uses Gutenberg as editor in all areas (editing posts, pages and widgets).
In my localhost (dev environment), all features are working very well, just like expected. But, in my client's preview server, the Widgets block editor shows an error when I try to update changes.
Checking the inspector, I can check my localhost does three API calls when I click "Update" button... The first is an OPTIONS requests, that returns information for the next calls (like endpoint and data). The second request is a POST request, that actually saves my changes, and the third request is a GET request, to check if changes are saved successfully and to update the view.
In preview server, the first request (the OPTIONS) is returning an status code of 200 OK, but the response is empty, unlike in my localhost, that returns a JSON response. Also, the console has no errors, and, even enabling WP_DEBUG, no errors are shown, even in server logs.
My localhost configuration is:
Linux Mint 20.3
Apache Server 2.4.41
PHP 7.4.3
MariaDB 10.3.32
The client's preview server is:
Windows Server 2012 R2 DataCenter
IIS Server (I don't know the version)
PHP 7.4.1
MySQL 8.0.19
My guess is IIS Server has something wrong configured, that is making the OPTIONS request to return empty responses. But, in fact, I don't know what is going wrong, because I'm not an expert in Windows Servers (I work most with Linux servers), and three people already tried to help and fix that, but no one has managed to solve the problem.
Can someone help me with this?
I'm using IIS 10 server as a gateway for Node.js server.
When client calls download files such as zip file, IIS server download Node.js server internally with HTTP protocol, and then it pass to client with HTTPS.
But in Chrome web browser, It shows error
net::ERR_HTTP_1_1_REQUIRED with status 200, and when I try to download again it works well until I clear the caches.
In Firefox, it returns status 200 too, but nothing's happen.
In Microsoft Edge and IE11 works well too.
I've set enough timeout and buffer size in IIS.
May Chrome and Firefox go wrong at HTTPS - HTTP connection or something else?
There may be some extensions in your Firefox and Chrome that can cause this error. This error means a browser extension blocked the request. The most common culprit is an ad blocker like AdBlock Plus. In short your requests to server have been blocked by an extension. so you can try to disable these extensions and try again.
It seems that the .NET Core team found a related issue and provided a workaround.
Perhaps the same can be applied with other frameworks.
https://github.com/dotnet/aspnetcore/issues/4398
Apparently, when doing an ajax request from a browser, it will sometimes send an OPTIONS request before the real request with a 204 status code which causes the problem.
For me, it seems to have solved my problem to return the file with a response content-type of "text/plain" instead of "application/octet-stream"
I'm not really sure why it works, it just does.
I have a couple Azure VMs behind a Basic Load Balancer with an HTTP URL Health Probe for the Backend Pool. To mark a server down, that URL returns Status Code 503 (Service Unavailable), but when I call that page from those VMs, the Status Code returned is 403. That still has the desired effect, I suppose, of marking the server down - but I dont understand why the code I set has changed.
This is from an ASP.NET web forms application on the VMs. I look at developer tools in the browser, and from my local machine or from a Dev server on our local network, that page returns Status Code 503, but calling that page from the VMs in Azure, the Status Code is 403.
Here's where I set the Status Code in that page:
Response.Clear()
Response.StatusCode = 503
Response.Flush()
I suppose I should mention that my local is a Windows 10 box, and the server VM is Windows Server 2016. Both are running IIS 10. The application is compiled with .NET Framework 4.6.
Here's the dev tools from my localhost:
Here's the dev tools from the server in azure:
Why the change? Anything I can do to stop this behavior?
So today I tried enabling Failed Request Tracing, but either something wasnt set up correctly, or the error was being handled elsewhere, and didnt result in any failed requests being logged.
Since I wasnt getting any failed requests logged, I opened up Process Monitor and could see that immediately after the call to my Health Probe page, I was getting a call to my custom HTTP Error page. That page must have been what was giving the 403 (dont know why, b/c that page works correctly for other HTTP Errors with a friendly error message and logging of the error to my custom error tracking solution).
I was going to change the Status Code to see if there was something special with the 503 that I was setting that was handled differently in IIS, but that got me thinking about how I was setting the status code...
In my research today, I saw this page https://www.leansentry.com/HowTo/AspNet-Response-Flush-Poor-Performance which cautions against using Response.Flush(). The code that I had implemented was in the Page_PreRender method, so there's not really a need to Flush there anyway.
I removed the Response.Flush and of course, my troubles went away.
The Health Probe page no longer triggers an Error from the Azure VM, and therefore, the status code that I get in my client browser is the 503 that I set in code.
So I guess this case is closed. I will need to figure out why the HTTP Error page was throwing a 403 instead of returning the friendly error message, but that should be easy enough...
All of a sudden all of my websites on my server return 400 Bad Request Error. I don't have a clue what happened. App Pools are running in Classic pipeline mode (4.0, 2.0), doesn't matter.
Every URL that I type comes back as 400 Bad Request. Real URLs, even fake URLs that don't exist (which should come back as 404) all are 400.
http://mywebsite.com/AFile.aspx
http://mywebsite.com/AFolder/AnotherFile.aspx
http://mywebsite.com/Bfolder/YetAnotherSillyPage.aspx
http://mywebsite.com/A_stupid_URL_that_does_not_even_exist_fjfjffjfj.aspx
Everything 400 Bad Request. Totally screwed up my ASP.NET. Where should I begin to look? Machine.config? Web.config?
UPDATE:
After trying a million different settings, I finally set the App Pool to Integrated and set the Identity to LocalSystem and all of a sudden it works.
Bad Request usually is HTTP.sys stopping the request due to something really bad (like invalid URLs, or something like that).
You probably should look at HTTP.sys logs (Not IIS) at:
C:\Windows\System32\LogFiles\HTTPERR
Also, maybe something got broken in the http.sys configuration so try running:
netsh http show servicestate
And see if for your web site it has the correct bindings, for example it could be that the bindings are only listening on only specific IP Addresses and yet its coming from another one, or similar problem but with Host Name, etc.
Finally you might want to run:
C:\Windows\System32\inetsrv\appcmd list sites
And see if the bindings and status makes sense.
Have you tried some mixture of re-installing (or uninstall/install) asp.net using the aspnet_regiis.exe utility? That's fixed strange IIS/ASP.NET server issues for me in the past.
Have you looked in the event log for any error messages or further clues?
I'm attempting to configure a webdav server example application (https://sourceforge.net/projects/webdav/) to run on IIS6 (Win2003 Server). The application runs correctly on my dev machine (Win7, IIS7.5).
When I attempt to map a drive to the DAV share, several requests are issued, including one OPTIONS request and two PROPFIND requests.
In Fiddler, I see that these are transmitted correctly. However, the response is always the content of the default page on the site. If I look at the IIS logs, the requests are logged as GETs instead of OPTIONS or PROPFIND.
UrlScan is disabled, but I went ahead and added OPTIONS and PROPFIND to the list of allowed verbs (since I'm running out of ideas).
Help.
Solved.
Turns out that URLScan wasn't disabled, though it was not listed in the ISAPI filter list in IIS Manager. Just for kicks I renamed the URLScan.ini file, which resulted in an exception when any site on the server was hit.
Rather than removing URLScan completely (following the Prime Directive), I modified the denyVerbs and DenyHeaders sections to allow all of the DAV stuff.
I'll accept an answer from the first person to provide a clear explanation of what security problems this may introduce if put in production.