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

Notification

Icon
Error
2 Pages12>
HTTP Error 400 Bad Request
Options
Previous Topic Next Topic
dreka
#1 Posted : Monday, March 14, 2016 9:23:43 AM(UTC)
Groups: Member
Joined: 3/14/2016(UTC)
Posts: 10
Hi,

I'm running UltiDev Web Sever Pro v2.0.21 and I've a strange case where a scanner device embedded browser is unable to surf any .NET 4 website/web application created inside UltiDev because a Bad Request error is generated. If I create the same site inside IIS than everything work perfectly, it works as well if the same site is set to run with .NET 2/3 under UltiDev.

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:

POST http://10.10.10.145:8888/Default.aspx HTTP/1.0
Accept: image/png, image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Host: 10.10.10.145:8888
....

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. Unfortunately I cannot change this because the request is created by the embedded scanner browser but the same request looks like accepted by IIS/.NET4 or UltiDev/.NET2-3, why the combination UltiDev/.NET4 produces this problem? Is there a way to overcome to it?

It can be replicated by sending a similar raw request via telnet.


Thanks,
Luigi
Back to top
Ultidev Team
#2 Posted : Tuesday, March 15, 2016 8:51:23 AM(UTC)
Ultidev Team

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

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hi there!

We'll be happy to try helping in troubleshooting this problem.

Would it be possible for you run Fiddler tool on the client machine, run both successful and problematic requests through Fiddler, save trace "sessions" files and attach them to your next reply?

If you could send examples from both UWS and IIS, it would be help us compare the differences.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
dreka
#3 Posted : Tuesday, March 15, 2016 11:24:48 AM(UTC)
Groups: Member
Joined: 3/14/2016(UTC)
Posts: 10
Hi,

I can't run Fiddler because as said it is a MFP (scanner device) with an embedded browser.

In order to replicate the same behavior out of the scanner I've created a small C# application which sends the same kind of request to the webserver via telnet. Please find it attached. There are both a bad request and a good request strings which are different in just the requested resource as explained. Have tried to capture network with Wireshark but it doesn't give much information more than just the request itself (same as written in this test application) and the bad request (or good) reply from the webserver.


Regards,
Luigi
File Attachment(s):
WindowsFormsApplication.zip (47kb) downloaded 156 time(s).
Back to top
Ultidev Team
#4 Posted : Wednesday, March 16, 2016 1:45:18 PM(UTC)
Ultidev Team

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

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hi!

Do you mean that along with the browser, UWS and your web application also run on the scanner device? If only browser runs on the device, and the server+app run remotely on another system, than you could simply use another PC instead of the scanner to try to reproduce the problem, by hitting the same URL from Fiddler, and easily play with headers to see what may be causing the problem.

Just in case, we ran our standard "I'm alive" web app that comes along with UWS and hosted on http://localhost:7756/ and tried to reproduce. We were unable too. Please see attached screenshot and Fiddler trace capture.

Best regards,
UltiDev Team.
File Attachment(s):
UWS POST with full host (rename .zip to .saz).zip (12kb) downloaded 145 time(s).
Ultidev Team attached the following image(s):
Ultidev Team attached the following image(s): UWS POST with full host name.png
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
 |  Edit by user
dreka
#5 Posted : Wednesday, March 16, 2016 2:53:52 PM(UTC)
Groups: Member
Joined: 3/14/2016(UTC)
Posts: 10
Hi,

no only the browser is on the scanner device but as initially stated the specific behavior is only occurring when the page would be browsed from the scanner browser, not from a normal PC browser (that's why you won't be able to reproduce).

I've already debugged out to try to reproduce without the scanner browser to keep it simple and I found out the specific reason in the header of the request, have posted explanation and also sample test application to reproduce from a normal PC.

Please have a look to my previous explanation, it occurs only when the requested resource in the request header is posted with the full http URL (behavior used by the scanner browser), although this isn't usual it works with IIS and it works with Ultidev as well but only when the web application is set to run with .NET 2/3.5.

Please check the sample application I've attached, it is making a telnet connection reproducing the exact request from the scanner browser, hence reproducing the bad request reply from Ultidev when using .NET 4.
Back to top
Ultidev Team
#6 Posted : Thursday, March 17, 2016 11:25:45 AM(UTC)
Ultidev Team

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

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hi,

We were able to reproduce the problem using your sample application, but so far we don't know the root cause. It may take a while to figure out what is wrong, exactly. Meanwhile, we also noticed that seemingly identical request sent from Fiddler works just fine. Here'e the request we successfully used with Fiddler (200 success capture is attached):
Code:

POST http://127.0.0.1:8380/Default.aspx HTTP/1.0
Host: 127.0.0.1:8380
Content-Length: 22

MFPApplicationName=App


Here's what we can suggest: we noticed that in your code you are using low-level socket comm to implement HTTP protocol. While this is certainly one way to do it, it's a risky and sub-optimal way to do it, since it makes it easy commiting subtle protocol violations that may be tolerated by one web server, but not by every one. HttpClient and WebClient classes would be much more reliably compliant with HTTP protocol.

Since troubleshooting this problem from our side will require debugging it with UWS source code, and since we think it may be caused by possible client's HTTP protocol violation, we'll be able to get to it probably only in the beginning of April. If you could reproduce this problem using Fiddler, it would be helpful, because then we'd know that this issue is not caused by client's http protocol violation.

Best regards,
UltiDev Team.
File Attachment(s):
UWS simple POST (rename .zip to .saz).saz.zip (12kb) downloaded 148 time(s).
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
dreka
#7 Posted : Thursday, March 17, 2016 12:32:35 PM(UTC)
Groups: Member
Joined: 3/14/2016(UTC)
Posts: 10
Hi,

glad to hear you were able to replicate. Indeed the low level communication is not what is intended to be used but I've used it for the simple reason that it was the only way I could replicate this behavior on a PC, in order to get you as well replicate it. Perhaps the scanner browser may violate something in the request, and it would be nice if you can indeed debug it also at the beginning of April, wondering with IIS doesn't produce the issue and also Ultidev when running with .NET 2/3.5 instead of 4.

Will wait for further news from your side and if in the mean time I'll be able to replicate with Fiddler as well I'll certainly let you know.

Thank you very much.

Best Regards,
Luigi
Back to top
Ultidev Team
#8 Posted : Thursday, March 17, 2016 3:37:53 PM(UTC)
Ultidev Team

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

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hi,

Could you please clarify the following: you've mentioned that UltiDev for 2.x/3.x does not have this problem. Are you talking about the old "UltiDev Cassini" web server, or the new "UltiDev Web Server Pro" (UWS) when it runs CLR2 apps?

Thank you,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
dreka
#9 Posted : Thursday, March 17, 2016 3:42:26 PM(UTC)
Groups: Member
Joined: 3/14/2016(UTC)
Posts: 10
Hi,

I'm talking about UWS with a CLR2 host, that's the strangest thing.

Regards,
Luigi
Back to top
Ultidev Team
#10 Posted : Friday, March 18, 2016 8:33:50 AM(UTC)
Ultidev Team

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

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Wow, that's really unexpected - but we've confirmed that's the case. We'll keep you posted on our progress.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
dreka
#11 Posted : Friday, March 18, 2016 8:39:36 AM(UTC)
Groups: Member
Joined: 3/14/2016(UTC)
Posts: 10
Hi,

Great, thank you very much! Looking forward to hear more.


Best Regards,
Luigi
Back to top
dreka
#12 Posted : Monday, May 23, 2016 5:21:05 AM(UTC)
Groups: Member
Joined: 3/14/2016(UTC)
Posts: 10
Hi,

do you have any updates on this issue?

Thank you.

Best Regards,
Luigi
Back to top
Ultidev Team
#13 Posted : Monday, May 23, 2016 1:25:20 PM(UTC)
Ultidev Team

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

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Sorry, we are still working on another issue ahead of this one. We'll keep you posted.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
Ultidev Team
#14 Posted : Monday, May 23, 2016 11:05:51 PM(UTC)
Ultidev Team

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

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hi!

We've gone through tracing of the requests that fail on CLR4, and determined that HttpRuntime.ProcessRequest() - the ASP.NET request processor - works differently for the reasons unknown.

UWS serves mostly as an intermediary between two very high-level Microsoft components: HttpListener (http.sys driver), and HttpRuntime - the ASP.NET application request processor. Once control is passed to the ASP.NET request processor using HttpRuntime.ProcessRequest(), then .NET Framework calls all the shots, by invoking a bunch of virtual functions of the SimpleWorkerRequest subclass. What we've found is that this sequence of SimpleWorkerRequest method calls is different between "good" and "bad" requests. We also can tell that HttpListenerContext - a pre-parsed http request arriving from HttpListener, looks identical in both cases, and only ASP.NET flow handling the request works differently: with bad request right after beginning of processing the request, it invokes SendStatus() with 400 and "Bad request" as arguments. Effectively, when running under CLR4, ASP.NET decides that something is wrong with the request and tells UWS to tell HttpListener to go away with 400. Our code for request processing is the same source, and arriving requests look identical, but ASP.NET flow is not the same for some reason.

We will research this problem, but if logic leading to this outcome proves to be inside the .NET Framework logic, we are unlikely to be able to resolve this problem.

We'll keep you posted.

Best regards,
UltiDev Team.

Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
dreka
#15 Posted : Tuesday, May 24, 2016 10:57:33 AM(UTC)
Groups: Member
Joined: 3/14/2016(UTC)
Posts: 10
Hi,

thank you very much for the update, will wait for further news.

Keep in mind that IIS, instead, works correctly on both CLR by using the exact same web application and request used in Ultidev. So there must be something handled differently by the web server as well.

Best Regards,
Luigi
Back to top
Guest
#16 Posted : Sunday, May 29, 2016 6:06:34 AM(UTC)
Groups:

Message was deleted by a Moderator.
Back to top
| Reason
Guest
#17 Posted : Sunday, May 29, 2016 9:43:42 AM(UTC)
Groups:

Message was deleted by a Moderator.
Back to top
| Reason
Guest
#18 Posted : Saturday, June 4, 2016 3:21:35 AM(UTC)
Groups:

Message was deleted by a Moderator.
Back to top
| Reason
dreka
#19 Posted : Wednesday, August 24, 2016 4:36:33 AM(UTC)
Groups: Member
Joined: 3/14/2016(UTC)
Posts: 10
Hi,

are there any updates on this topic?

Thank you very much.

Kind Regards,
Luigi
Back to top
Ultidev Team
#20 Posted : Wednesday, August 24, 2016 1:34:47 PM(UTC)
Ultidev Team

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

Thanks: 28 times
Was thanked: 60 time(s) in 59 post(s)
Hi,

At this point it seems unlikely that we'll be able to get to the bottom on why .NET framework request processing callback sequence invoked by HttpRuntime.ProcessRequest() is different in CLR4. We are sorry, we we don't know what makes CLR4 version of HttpRuntime.ProcessRequest() decide in this specific case that the request is bad and tell us to return 400 code.

Best regards,
UltiDev Team.
Please donate at http://www.ultidev.com/products/Donate.aspx to help us improve our products.
Back to top
WWW
Rss Feed  Atom Feed
Users browsing this topic
Guest (12)
2 Pages12>
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.

Powered by YAF 1.9.5.5 | YAF © 2003-2011, Yet Another Forum.NET