A web-server is returning a status code and description in response to a request by an XmlHttp component. The actual status response from the server begins with:
HTTP/1.1 400 Not a valid http POST request
which i can see in though a Fiddler trace:
But when i ask the xmlHttp request for the status and statusText, it shows me the "standard" description for the status text, rather than the actual status text:
xmlHttp.status: 200
xmlHttp.statusText: "Bad Request"
which i can see in in the development IDE:
i've poked around all the other properties of IXMLHttpRequest, and i can't find any that contain the response's actual status text. It's not even in any of the response headers:
Server: ASP.NET Development Server/8.0.0.0
Date: Thu, 28 Jan 2010 21:03:16 GMT
X-AspNet-Version: 2.0.50727
X-LSI-Proxy-Identificaton: {65B76AB2-8A28-4A2B-B282-7E1FDC9DBCA1}
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/xml; charset=utf-8
Content-Length: 4652
Connection: Close
Internet Explorer, Chrome, and FireFox manage to read the actual status text:
How can i get the actual statusText from a Microsoft xmlHttp object?
Unfortunately code 400 is defined as Bad Request as part of the HTTP/1.1 RFC and XMLHTTP (well more likely URLMON or WinHTTP) is just transforming the number and ignoring the passed status text. As the status line is part of the protocol and not a response header then it makes sense it isn't defined in the list of response headers.
However I would contend that the browsers are only showing the status text "correctly" because they are displaying the custom HTML page which got sent along with it which has that text as the TITLE in the HEAD element.
Related
When I send the following http post request:
POST /query.fcgi HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 63
form_state=3&form_name=system_sw_upgrade&field_name=http_upload
The server responds with a BAD Request
What's wrong with the request?
Your request is missing a Host header. From the spec (see 14.23):
A client MUST include a Host header field in all HTTP/1.1 request messages . If the requested URI does not include an Internet host name for the service being requested, then the Host header field MUST be given with an empty value. An HTTP/1.1 proxy MUST ensure that any request message it forwards does contain an appropriate Host header field that identifies the service being requested by the proxy. All Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request) status code to any HTTP/1.1 request message which lacks a Host header field.
I'm trying to implement a simple web browser in C.
When ever I send a get request to google.com using
GET / HTTP/1.1\r\n\r\n
I receive
HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: http://www.google.co.in/?gfe_rd=cr&ei=1wIjWPqZA6DmugSY4I-IDw
Content-Length: 261
Date: Wed, 09 Nov 2016 11:04:55 GMT
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
here.
</BODY></HTML>
Subsequently I send another GET request
GET /?gfe_rd=cr&ei=1wIjWPqZA6DmugSY4I-IDw HTTP/1.1\r\n\r\n
And I receive error code 404 not found.
If not this, what should be the GET request to redirect me to the site. I find ip address of google using
char *hostname = "www.google.com";
struct hostent *he;
he = gethostbyname( hostname );
You're requesting the wrong URL.
Take a closer look at the URL given in the Location header:
http://www.google.co.in/?gfe_rd=cr&ei=1wIjWPqZA6DmugSY4I-IDw
and the URL in the HTML source:
http://www.google.co.in/?gfe_rd=cr&ei=1wIjWPqZA6DmugSY4I-IDw
You'll notice that the second of these is slightly different, because ampersands have to be encoded as & in HTML documents.
If you use the URL in the Location header, you stand a better chance of success. However, you might still have problems if the server's behaviour depends on other factors. For example, a lot of websites will reject requests without a recognisable User-Agent request header.
Basically I am using a POST method but it automatically gets converted to OPTIONS method. I know browser does this but also read that it is fine and should get response as 201, but in my case it is not behaving as expected, I have also tried Access-Control-Allow-Methods in request headers but didn't get anything.
This is what my Request looks like:
OPTIONS http://xyz/abc
Accept: application/json
Content-Type: application/json
Response:
405, Method Not Allowed
Access-Control-Allow-Origin: *
Date: Tue, 05 May 2015 06:15:19 GMT
Connection: close
Accept-Ranges: bytes
Access-Control-Allow-Headers: authorization, content-type
Content-Length: 0
Access-Control-Allow-Methods: GET, PUT, POST, DELETE, HEAD
Can anyone tell me the cause of this issue and what could be the exact reason for the same after having enough research everything looks fine at my end.
Thanks in advance.
You are probably seeing pre-flight check during a POST-request in cross-origin resource sharing. I don't know how your webserver needs to be setup to support this, but this Wikipedia article might be a first help: http://en.wikipedia.org/wiki/Cross-origin_resource_sharing
The easiest solution is to do the POST request on the same origin as the where you are loading the web-page from. A reverse proxy might be a reasonable solution.
I am familiar with the 301 error code but new to http requests and formatting them correctly.
In my program i need to retrieve my school's homepage, but i get a 301 Moved Permanently header. The header's location says where the page moved to, but even that new location won't work for me, probably because i didn't format it correctly.
Initially i send this request:
GET / HTTP/1.1\r\nHost: www.cs.uregina.ca\r\nConnection: close\r\n\r\n
And receive this header:
Received: HTTP/1.1 301 Moved Permanently
Date: Tue, 04 Nov 2014 05:38:42 GMT
Server: Apache
Location: http://www.cs.uregina.ca/
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8
What should my new HTTP request look like to get the above moved webpage?
If i try the location of the moved page like it suggests then i get the following 400 Bad Request Response:
GET / HTTP/1.1\r\nHost: http://www.cs.uregina.ca\r\nConnection: close\r\n\r\n
Received: HTTP/1.1 400 Bad Request
Date: Tue, 04 Nov 2014 05:52:36 GMT
Server: Apache
Content-Length: 334
Connection: close
Content-Type: text/html; charset=iso-8859-1
Initially i send this request:
GET / HTTP/1.1\r\nHost: www.cs.uregina.ca\r\nConnection: close\r\n\r\n
And receive this header:
Received: HTTP/1.1 301 Moved Permanently
...
Location: http://www.cs.uregina.ca/
...
This is exactly what I get when I request cs.uregina.ca. You have probably connected to cs.uregina.ca (or some subdomain other than www), or to an IP address the does not correspond to www.cs.uregina.ca.
If i try the location of the moved page like it suggests then i get
the following 400 Bad Request Response:
GET / HTTP/1.1\r\nHost: http://www.cs.uregina.ca\r\nConnection: close\r\n\r\n
Received: HTTP/1.1 400 Bad Request
...
This is not surprising. You must remove the http:// protocol from the Host: header. Eg:
GET / HTTP/1.1\r\nHost: www.cs.uregina.ca\r\nConnection: close\r\n\r\n
In general, when requesting a URL such as the following:
http://domain.example:80/path/to/resource/?query#fragment
---- -------------- ==------------------------
protocol host | path
port
you would:
resolve the host name to an IP address, and connect to that IP address on port (if present in the URL) or the default port associated with the protocol.
Communicate with the server using a mechanism specific to protocol. In this case, an HTTP request.
Request path from the server with an appropriate Host: header (in case there are multiple hosts on the same IP).
The fragment identifier is used with (X)HTML and is not actually sent to the server.
The request should (at a minimum) look like this:
GET /path/to/resource/?query HTTP/1.1
Host: domain.example
Connection: close
The full details can be found in:
RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing.
RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content.
RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests.
RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests.
RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching.
RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication.
If you just want the homepage, download nc and type "nc www.cs.uregina.ca 80"
When nc starts type the following and then hit return twice:
GET http://www.cs.uregina.ca HTTP/1.0
We're having an issue with restangular and handling errors from the API. If the API responds with a 200, then everything works perfectly. However, when the API returns a 409 we receive a lovely:
XMLHttpRequest cannot load https://**token=*. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://127.0.0.1:9000' is therefore not allowed access.
Response headers from a valid post operation:
Access-Control-Allow-Credentials:true
Access-Control-Allow-Headers:Origin, X-Requested-With, Content-Type, Authorization, Accept, X-Authorization, User-Agent, DNT, Cache-Control, X-Mx-ReqToken, Keep-Alive, If-Modified-Since
Access-Control-Allow-Methods:GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Origin:http://127.0.0.1:9000
Access-Control-Max-Age:1728000
Cache-Control:private, must-revalidate
Connection:keep-alive
Content-Type:text/html; charset=utf-8
Date:Fri, 29 Aug 2014 21:55:51 GMT
ETag:"*****"
Server:nginx/1.6.0
X-Frame-Options:SAMEORIGIN
X-Powered-By:HHVM/3.3.0-dev+2014.08.22
Response headers from a post operation with a 409 response captured from postman:
Cache-Control →no-cache
Connection →keep-alive
Content-Encoding →gzip
Content-Type →text/html; charset=utf-8
Date →Fri, 29 Aug 2014 21:56:59 GMT
Server →nginx/1.6.0
Transfer-Encoding →chunked
X-Frame-Options →SAMEORIGIN
X-Powered-By →HHVM/3.3.0-dev+2014.08.22
Any attempt to catch the response.status or error handling as outlined in the
restangular docs results in this:
config: Object
data: ""
headers: function (name) {
status: 0
statusText: ""
I always have a status of 0.
Let me know if you need to see any additional information.
This really has nothing to do with restangular but with your webserver config.
What is happening is that your webserver isn't set up to return the CORS headers in case an error occurs.
Because of this you can not access any of the returned data from the ajax request, even tough data was actually returned. You won't even be able to see it in chrome's network inspector ( except for the status code and headers ). Additionally, because this is a security violation, you can't even access the status code, headers or anything from javascript everything is being blocked.
You will however be able to see it in a proxy like fiddler or charles, or when you make the request directly to the api server ( in case of a GET request ), because a request was actually made and data will have been returned, the browsers security policies just denies access to it trough AJAX because of the missing CORS headers.
This doesn't mean you can just fire off ajax requests to any other domain and possibly interact with it. The only reason your requests are going trough in the first place is because the preflight OPTION request is set up to allow CORS
Solution:
Set up your WebServer to include CORS headers in case an error response is generated, the headers you are looking for are all available in the valid response you supplied ( Access-Control-* ).