Welcome Guest! To enable all features please Login or Register.



2 Pages<12
HTTP Error 400 Bad Request
#21 Posted : Wednesday, August 24, 2016 4:16:18 PM(UTC)
Groups: Member
Joined: 3/14/2016(UTC)
Posts: 10


I may understand your reply if I was not a developer myself but being such I cannot, especially when saying the problem is somewhere else.

The error is quite clear because I've explained it in the post creation already, I'll report it again below:

Debugging bit more found that the problem is due to how the scanner embedded browser is creating a request, below there is a sample header:

Accept: image/png, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

and the problem is in the requested resource, if it is changed to "POST /Default.aspx HTTP/1.0" (so removing full host information) it works perfectly

With a sample application I can emulate the bad request and also fix by changing the requested resource. In fact IIS, using the same .NET 4 processor, can serve perfectly the request which means they do something different from Ultidev and which Ultidev can do as well.

Could you please take in consideration the above example? Perhaps .NET 4 is appending the HOST before the resource or something similar very simple making the request bad when the browser will receive such request info, but this can be easily verified by you in debugging by changing the resource as per above while debugging.

Normally this should be fine also in general according HTTP specifications, so perhaps you can find a fix by changing it, when running on .NET 4, if you receive such requests which we know will be considered bad by the framework.

Thanks and Regards,
Luigi Zurolo
Ultidev Team
#22 Posted : Thursday, August 25, 2016 8:59:27 AM(UTC)
Ultidev Team

Groups: Administration
Joined: 11/3/2005(UTC)
Posts: 2,253

Thanks: 28 times
Was thanked: 59 time(s) in 58 post(s)
Hi, Luigi.

IIS does not use exactly the same request processor. In fact, .NET Framework 4 has a completely one-off, IIS-specific, closed version of the request processor: http://referencesource.m...ng/IIS7WorkerRequest.cs - just for IIS. It results in several differences in how requests are processed by IIS and everyone else. Also, IIS appears to be using low-level C/C++ interface with http.sys driver, and the not HttpListener .Net class - a simplified version with lots of restrictions, exposed to the .NET world. In other words, IIS request processing pipeline is proprietary, much more low-level and vastly more complex.

We do not have an opportunity to change the request after it came from HttpListener class as the request is already ingested and pre-parsed by the http.sys driver. We simply take it and hand it off to the HttpRuntime.ProcessRequest(), which then tells us to return 400 in the response.

We try to be as compatible with IIS as possible, but in order to be 100% compatible, we'd have to rewrite IIS.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
#23 Posted : Wednesday, February 28, 2018 9:04:33 PM(UTC)

Message was deleted by a Moderator.
Rss Feed  Atom Feed
Users browsing this topic
2 Pages<12
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You can vote in polls in this forum.