I was comparing headers of same HTTP Post request for Firefox and Internet Explorer and I see that for IE.
I was wondering:
What does Accept: */* mean under Client section of Request Headers?
The accept: header defines the content type the client accepts, or expects to be returned by the server. Depending on the situation this can be text/css, text/html, image/png, .. etc. - just some mime type.
The * character is considered the wildcard. accept: */* simply means that any data of whatever mimetype is accepted and the server may choose what to return to the requesting client.
It's answered in the specification. See http://greenbytes.de/tech/webdav/rfc2616.html#header.accept and http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-21.html#header.accept
Related
How should an HTTP Agent make decisions about using cached response when a request has the same path but different headers?
Take for example this HTTP request/response:
GET /resource HTTP/1.1
Host: example.org
X-Filter: foo=bar
HTTP/1.1 200 OK
Cache-Control: max-age=3600
Content-Type: application/json
Content-Length: 13
{"foo":"bar"}
Should the agent consider the response valid for a second request with a different X-Filter header? For example:
GET /resource HTTP/1.1
Host: example.org
X-Filter: foo=baz
then within an hour from the first request, should the agent request a fresh response since the request header differs, or should use the cached response from the first request, ignoring the header?
I'm asking this because I noticed that Google Chrome makes a new request, Microsoft Edge instead use the cached response.
You should use the cached version unless changed header appears in the list provided by the (optional) Vary response header.
For example, a response that contains
Vary: accept-encoding, accept-language
indicates that the origin server might have used the request's
Accept-Encoding and Accept-Language fields (or lack thereof) as
determining factors while choosing the content for this response.
I am trying to send the description in form data to create an issue but it seems it is only possible through parameters with a length restriction. Does anybody know a way around this or am I doing something wrong?
PUT /rest/issue?project=LSDebug&summary=Debug%2520Log HTTP/1.1
Connection: keep-alive
Content-Length: 266
Accept: application/json, text/plain, */*
Origin: http://localhost:8080
Content-Type: application/x-www-form-urlencoded
Referer: http://localhost:8080/index.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Query String Parameters
project:LSDebug
summary:Debug%20Log
Form Data
description=Submitted%20Form%20name%3A%20null%2C%20Id%3Anull%0D%0AInput%20name%3A%20null%2C%20Id%3Anull%2C%20NgModel%3Aresult.homeTeamScore.score%2C%20Value%3A%201%0D%0AInput%20name%3A%20null%2C%20Id%3Anull%2C%20NgModel%3Aresult.awayTeamScore.score%2C%20Value%3A%202
I think you need to embed the data in XML within the body of your PUT request as documented in the Import REST API docs.
Html forms only support GET or POST. So i would suggest you to post the form data using POST method instead of PUT. So that the form content will go into the body of the message and you will able to evade the URL restriction
Normally, one would use BatchHttpRequest to aggregate several requests, but what if I want to list files for two different users?
Nominally that requires an oauth2 token per-user. BatchHttpRequest either takes one http object (which handles the credentials) for the batch, or pulls it out of the first batched request encountered when .execute() is called.
Using oauth1 to sign each batched requests results in proper results (different feeds for each user). However, using oauth2 and manually constructing the payload results in identical feeds (matching the user in the first batched request):
POST /batch HTTP/1.1
Host: www.googleapis.com
Content-Type: multipart/mixed; boundary=blah
Content-Length: 572
accept-encoding: gzip, deflate
Cache-Control: no-cache
--blah
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: <b29c5de2-0db4-490b-b421-6a51b598bd22+1>
GET /drive/v2/changes HTTP/1.1
Authorization: Bearer ya29.UQAabvlG2hnRPyEAAADUm7vkDe_qg7L49R655IyxvgBnkN7_PEgE3IG7UnZ_ZEmJwUK_6fSV4kTHjNQIjTk
accept: application/json
--blah
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: <b29c5de2-0db4-490b-b421-6a51b598bd22+2>
GET /drive/v2/changes HTTP/1.1
Authorization: Bearer ya29.UQBu8f9W8S5E6RwAAAAPqCOiqoFW3QEFYkBvQGx36UVKNHeEhdZT8GPN-P74ng
accept: application/json
--blah
Since oauth1 works, it seems that this is at least theoretically possible, although I may be blocked by a google bug where the oauth2 token for the first request in the batch overrides any other authorizations included.
The google-provided client does not support this, but providing an Authorization header for each request will work. The example given should work assuming all of the authorization header values are correct.
Request header (from Firebug):
Accept application/json, text/plain, */*
Accept-Encoding gzip, deflate
Content-Type application/json;charset=utf-8
Request json:
{"key":"value"}
So how to get request body in perl?
What webserver?
Usually POST data is available by simply reading from STDIN.
If you are using the venerable CGI module (under mod_perl or not), you can get the body via:
$cgi->param('POSTDATA')
(if, as in this case, the content type isn't application/x-www-form-urlencoded or multipart/form-data)
Ok so I've been reading up on HTTP and found this page. This is an example HTTP request that was posted there:
GET /http.html Http1.1
Host: www.http.header.free.fr
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
Accept-Language: Fr
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0)
Connection: Keep-Alive
I tried it in telnet and it worked. But everywhere else I see this kind of request line
GET /http.html HTTP/1.1
The important different is that HTTP is all caps and the / character.
Are they both correct? They both seem to work on the sites I've tested it on. I've skimmed the RFC of HTTP but didn't find anything of use. Has anyone else seen this kind of request header? Is it officially supported?
Refering to the HTTP protocol, it must be in HTTP/1.1 or HTTP/1.0 (older one). Now it depend how the http server was developed. It may accept it but you should not rely on it.
EDIT:
your answer is here: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3 :
HTTP-Version = "HTTP" "/" 1*DIGIT
"." 1*DIGIT
And now the protocol is 1.1 so you should use: GET /http.html HTTP/1.1
According to RFC2145 (page 3),
RFC791 [4] defines the "robustness principle" in section 3.2:
an implementation must be conservative in its sending behavior, and liberal in its receiving behavior.
This principle applies to HTTP, as well. It is the fundamental basis for interpreting any part of the HTTP specification that might still be ambiguous. In particular, implementations of HTTP SHOULD NOT reject messages or generate errors unnecessarily.
And in particular:
It is, and has always been, the explicit intent of the HTTP specification that an implementation receiving a message header that it does not understand MUST ignore that header.
So the server is ignoring the version number in the case that it's "Http1.1" (which is not valid) and presumably it's interpreting the message as a HTTP/1.0 message (or maybe even HTTP/0.9!). Of course, you should not rely on this behaviour!
It should be
GET /http.html HTTP/1.1