Where does my HTTP 404 response come from?
230 views
Skip to first unread message
Christian Balzer
Apr 14, 2014, 12:37:43 PM4/14/14
to python-...@googlegroups.com
Hi!
We are using TornadoServer/3.2 at work for a service.
I'm charged with writing unit tests for a completely different application, but I need to talk to the service running on the tornado box.
When we make the following HTTP call using Java (Apache HTTP Client's Fluent API):
---
GET /service/api/exec/cmds?cmdfile=UrlEncodedUrlHere
Host: host.name.com:8001
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.3.1 (java 1.5)
---
Tornado / the service return what we would expect, namely Json:
---
HTTP/1.1 404 Not Found
Date: Fri, 11 Apr 2014 08:43:11 GMT
X-Service-Version: 5.7.4
Content-Length: 256
Content-Type: application/json; charset=UTF-8
Server: TornadoServer/3.2
{"json": "here"}
---
If we make pretty much the same call, using another Java library (Apache HttpClient 4):
---
Host: host.name.com:8001
Connection: Keep-Alive
User-Agent: Apache-HttpClient/4.3.1
(Java 1.5 minimum; Java/1.7.0_40)
---
we get the following (HTML) back, and don't quite know why:
---
HTTP/1.1
404 Not Found
Date: Fri, 11 Apr 2014 08:39:32 GMT
Content-Length: 69
Content-Type: text/html; charset=UTF-8
Server: TornadoServer/3.2
<html><title>404:
Not Found</title><body>404: Not Found</body></html>
---
Note the only differences in the request are the URI after the GET keyword, and the User-Agent header.
We used WireShark to capture those request/response pairs, so are pretty confident there is nothing else going through the pipes...
Is there a simple explanation as to why essentially the same two requests produce those different responses?
From what I understand (and I'm no expert in HTTP; in fact I'm pretty clueless when it comes to it, or Python, let alone Tornado, for that matter) adding the http://host.name.com:port part into the GET line shouldn't make a difference in this case? (Without having read any of it, http://tools.ietf.org/html/rfc2616#section-5.1.2 seems to back that up... ;-)
Is the problem maybe the (automatically added) Host header in the second request? Does Tornado in fact look for http://host.name.com:8001/http//host.name.com:8001/service...
Any pointers where to start looking would be much appreciated... :)
Best regards,
Christian
Lysander Trischler
Apr 14, 2014, 6:36:23 PM4/14/14
to python-...@googlegroups.com
Hi,
> […]
> http://host.name.com:8001/service/api/exec/cmds?cmdfile=UrlEncodedUrlHere*
> User-Agent: *Apache-HttpClient/4.3.1 (Java 1.5 minimum;
> Java/1.7.0_40)*
as you already said, the requested URIs are different. Drop the host
part in your GET line from the second request.
Regards,
Lyse
> […]
> If we make pretty much the same call, using another Java library
> (Apache
> HttpClient 4):
> ---
> *GET
> (Apache
> HttpClient 4):
> ---
> http://host.name.com:8001/service/api/exec/cmds?cmdfile=UrlEncodedUrlHere*
> User-Agent: *Apache-HttpClient/4.3.1 (Java 1.5 minimum;
> Java/1.7.0_40)*
> ---
>
> we get the following (HTML) back, and don't quite know why:
> ---
>
> HTTP/1.1 404 Not Found
> * Date: Fri, 11 Apr 2014 08:39:32 GMT*
>
> we get the following (HTML) back, and don't quite know why:
> ---
>
> HTTP/1.1 404 Not Found
> Content-Length: 69
> Content-Type: text/html; charset=UTF-8
> Server: TornadoServer/3.2
> <html><title>404: Not Found</title><body>404: Not Found</body></html>
> ---
>
> Note the only differences in the request are the URI after the GET
> keyword,
> and the User-Agent header.
> […]
> Content-Type: text/html; charset=UTF-8
> Server: TornadoServer/3.2
> <html><title>404: Not Found</title><body>404: Not Found</body></html>
> ---
>
> Note the only differences in the request are the URI after the GET
> keyword,
> and the User-Agent header.
as you already said, the requested URIs are different. Drop the host
part in your GET line from the second request.
Regards,
Lyse
Ben Darnell
Apr 14, 2014, 9:36:02 PM4/14/14
to Tornado Mailing List
On Mon, Apr 14, 2014 at 12:37 PM, Christian Balzer <christia...@gmail.com> wrote:
Is there a simple explanation as to why essentially the same two requests produce those different responses?From what I understand (and I'm no expert in HTTP; in fact I'm pretty clueless when it comes to it, or Python, let alone Tornado, for that matter) adding the http://host.name.com:port part into the GET line shouldn't make a difference in this case? (Without having read any of it, http://tools.ietf.org/html/rfc2616#section-5.1.2 seems to back that up... ;-)
In practice, the fully-qualified url form is only used for HTTP proxies and the path is used in all other cases. I actually thought that it was invalid to use the fully-qualified form for non-proxied requests, but now that I've read the relevant portion of the spec I see that I'm wrong. Looks like tornado should be updated to parse the full url if there is one.
-Ben
Is the problem maybe the (automatically added) Host header in the second request? Does Tornado in fact look for http://host.name.com:8001/http//host.name.com:8001/service...
Any pointers where to start looking would be much appreciated... :)
Best regards,Christian
--
You received this message because you are subscribed to the Google Groups "Tornado Web Server" group.
To unsubscribe from this group and stop receiving emails from it, send an email to python-tornad...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages