The 206 status code (w3.org) indicates a partial result in response to a request with a Range header.
So "clearly" if the requested document is e.g. 1024 bytes long, and the Range header is bytes=0-512 then a status code of 206 Partial Content should be returned. (Assuming that the server is able to return the content)
BUT what if the Range is bytes=0-2000?
Should 200 OK or 206 Partial Content be returned?
It seems to me that this isn't clearly defined in the specification -- or maybe I'm not reading the right place?
Why do I care?
I ask because the Varnish Cache seems to always return 206 Partial Content, whereas the Facebook Open Graph debugger seems to expect 200 OK. [1] [2]
Example: GET request to Varnish
(I receive the full document, and yet 206 Partial Content is returned)
> curl --dump-header - -H 'Range: bytes=0-7000' https://www.varnish-cache.org/sites/all/themes/varnish_d7/logo.png
HTTP/1.1 206 Partial Content
Server: nginx/1.1.19
Date: Mon, 14 Apr 2014 22:43:31 GMT
Content-Type: image/png
Content-Length: 2884
Connection: keep-alive
Last-Modified: Thu, 15 Dec 2011 12:30:46 GMT
Accept-Ranges: bytes
X-Varnish: 1979866667
Age: 0
Via: 1.1 varnish
Content-Range: bytes 0-2883/2884
Further w3 reference: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35
It doesn't matter. Both replies are valid.
(also note that the current specification is now http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p5-range-26.html, to be published as RFC soon)
Related
Does anyone know if there is a way to create an instance of NSHTTPURLResponse from a text file containing a raw HTTP response?
As an example, if I type curl -D - http://google.com in to terminal, I get the following:
HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Fri, 25 Mar 2022 18:30:04 GMT
Expires: Sun, 24 Apr 2022 18:30:04 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 219
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
here.
</BODY></HTML>
Note how the raw response includes:
The HTTP protocol
The response code and any message about the code
All of the response headers
And then, the actual body of the response.
I'd like to be able to somehow init an HTTPURLResponse from the raw HTTP data so it gets all the properties provided: response code, headers, etc, as well as the body.
The purpose of this would be for tests.
We currently exercise our response handling code using files holding data for just the response body. It'd be really convenient to also include other response details so that these can easily be exercised as well.
Ideally this would use the same code that iOS / Mac will be running to completely capture those element of the stack as well.
I don't see any way to get that header in akk-http. That header is removed from header list in HttpResponse.
I know there are methods that return the contentLength from entity:
HttpEntity.contentLengthOption
and
HttpEntity.contentLength on strict entity.
But that both calls are based on entity itself, and that's not what I want.
In my case I'm sending the Head request to server(riak) to check if the object has proper size. I don't want to get the whole object using Get. That should be just a test.
That's how the response looks like:
curl -I "http://req-to-riak"
HTTP/1.1 200 OK
X-Riak-Vclock: a85hYGBgzGDKBVI82eqS92f/Ot/EwOT3PoMpkTGPleHKa8WLfFkA
Vary: Accept-Encoding
Server: MochiWeb/1.1 WebMachine/1.10.8 (that head fake, tho)
Last-Modified: Fri, 12 Aug 2016 06:42:28 GMT
ETag: "5IVrr7tsZp1O4FHLnMSc30"
Date: Wed, 24 Aug 2016 12:53:32 GMT
Content-Type: image/gif
Content-Length: 290305
But akka still return 0
It's a bug of Akka-Http, see here: https://github.com/akka/akka-http/issues/377
I'm trying to set up a small Silex RESTFul server, and now I'm playing around with HTTP Headers.
One GET function checks If-Modified-Since header, and compares with database's Last-Modified item.
Here's a small code sample:
if($hasModifications){
$response = [items]
$statusCode = 200;
} else {
$response = ['result'=>'no modifications'];
$statusCode = 304;
}
return $app->json($response,$statusCode,$headers);
Whenever $statuscode!=200, I only get a blank page and also no custom header gets sent. This also breaks CORS because I can't set Access-Control-Allow-Origin header.
Should I be doing it some other way?
(PS: this is not the actual code, and also if I replace $statusCode for 200, then everything works back as normal)
Update:
So far, I guess from what I've been reading, that 304 statuses shouldn't send anything on response's body. But what about headers? If I don't comply with CORS, then the AngularJS Frontend will fail and I wouldn't be able to catch the "Not Modified" exception!.
Obviously, I can figure it out some other way. But it would be nice if I could have both things working properly (REST+CORS)!
Update 2:
var_dump($headers)
array(4) {
["Last-Modified"]=> string(29) "Fri, 21 Aug 2015 22:47:53 GMT"
["X-Status-Code"]=> int(304)
["Cache-Control"]=> string(25) "post-check=0, pre-check=0"
["Pragma"]=> string(8) "no-cache"
}
Notice that I'm using X-Status-Code to inform the true HTTP Status.
Right now, the response line of code goes as follows:
return $app->json($response,200,$headers);
If I changed 200 to 304, I can't see the output of var_dump (gives me an empty page). Also if I set 304 status with no header parameter, it is still the same.
Seems like return or $app->json clears the HeaderBag, since I'm using JDesrosiers\Silex\Provider\CorsServiceProvider(), and those headers parameters also get cleared.
This is the Raw HTTP Response taken from Firefox with Status Code 304:
Cache-Control: post-check=0, pre-check=0, private
Connection: Keep-Alive
Date: Sat, 22 Aug 2015 19:52:18 GMT
Keep-Alive: timeout=5, max=100
Server: Apache/2.4.7 (Ubuntu)
And this, with Status Code 200:
Cache-Control: post-check=0, pre-check=0, private
Connection: Keep-Alive
Content-Length: 25
Content-Type: application/json
Date: Sat, 22 Aug 2015 19:53:12 GMT
Keep-Alive: timeout=5, max=100
Last-Modified: Fri, 21 Aug 2015 22:47:53 GMT
Pragma: no-cache
Server: Apache/2.4.7 (Ubuntu)
X-Powered-By: PHP/5.5.9-1ubuntu4.11
X-Status-Code: 304
Apache strips out CORS headers on 304 status codes.
You can read more in issue #51223 and you can also find a patch which will fix this problem.
If you don't want or you can't recompile Apache, you could try running Nginx, which will leave the CORS headers in place.
I am posting to LinkedIn group discussion endpoint
http://api.linkedin.com/v1/groups/{group-id}/posts
and am getting different response from different servers.
Once from the production server, the response I get back contains only PART of the response
in JSON format
{
"url":"http:\\api.linkedin.com\v1\groups\{group-id}\posts",
"http_code":201,
"download_content_length":0,
"size_download":0,
"size_upload":363
}
once from the development server, the response i get back contains the FULL response
in JSON format
{
"http_code":201,
"url":"http:\\api.linkedin.com\v1\groups\{group-id}\posts",
"header_size":536,
"request_size":871,
"filetime":-1,
"ssl_verify_result":0,
"redirect_count":0,
"total_time":1.513264,
"namelookup_time":0.213188,
"connect_time":0.449284,
"pretransfer_time":0.449346,
"size_upload":421,
"size_download":0,
"speed_download":0,
"speed_upload":278,
"download_content_length":0,
"upload_content_length":421,
"starttransfer_time":1.51323,
"redirect_time":0,
"headers_recv":"HTTP/1.1 201 Created Server: Apache-Coyote/1.1 x-li-request-id: PJRKH2SBF1 Location: http://\\api.linkedin.com\v1\posts\{post-id} X-LI-R2-W-IC-2: frm.scp=%7B%22refTime%22%3A1372946874%2C%22A.5070905%22%3A360%7D X-LI-R2-W-IC-2: com.linkedin.container.drc=1%7EAPRG%2C1 X-LI-R2-W-IC-2: com.linkedin.container.rpc.cluster.serviceInfo=PROD-ELA4%2Fappreg%2F0.0.2000-RC1.20722%2Fela4-app0213%2Fi001 X-LI-R2-W-IC-2: com.linkedin.container.dsc=1 Content-Length: 0 Vary: Accept-Encoding Date: Thu, 04 Jul 2013 14:07:53 GMT "
}
You need to specify which information LinkedIn should return for the request.
https:\api.linkedin.com\v1\groups{group-id}/posts:(creation-timestamp,title,summary,site-group-post-url,creator:(first-name,last-name,picture-url,headline),likes,attachment:(image-url,content-domain,content-url,title,summary),comments:(creator:(first-name,last-name,picture-url),creation-timestamp,text),relation-to-viewer)
Don't forget to use https instead of http.
I'm writing a scraper using Curl and I found that a lot of pages include multiple redirecting headers, like:
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.0.4
Date: Thu, 17 Nov 2011 17:46:35 GMT
Transfer-Encoding: chunked
Location: http://secure.domain.net/track/NDg6MTE6MTU/?autocamp=TJ_ABC_VA_A02
HTTP/1.1 302 Found
Date: Thu, 17 Nov 2011 17:46:37 GMT
Server: Apache
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: nats_cookie=Bookmark; expires=Fri, 18-Nov-2011 17:46:37 GMT; path=/; domain=domain.net
Set-Cookie: nats=MjYwNjk6MTE6MTU%2C0%2C0%2C0%2C0; expires=Sun, 27-Nov-2011 17:46:37 GMT; path=/; domain=domain.net
Set-Cookie: nats_sess=00e48c685c9acbb37fcc3b7461b1ab81; expires=Sat, 25-Feb-2012 17:46:37 GMT; path=/; domain=domain.net
Location: http://www.domain.net/tour/?nats=MjYwNjk6MTE6MTU,0,0,0,0&autocamp=TJ_ABC_VA_A02
Transfer-Encoding: chunked
Content-Type: text/html
HTTP/1.1 200 OK
Date: Thu, 17 Nov 2011 17:46:39 GMT
Server: Apache
Transfer-Encoding: chunked
Content-Type: text/html
As you can see there are two headers with the "Location:" directive.
I'm just wondering why they do this.
Wouldn't be enough to include only one header?
The redirecting URLs are even different,
So which one is the "real" landing page?
Thanks.
When CURLOPT_FOLLOWLOCATION and CURLOPT_HEADER are both true and redirect/s have happened, the response returned by curl_exec() will contain all the headers in the redirect chain in the order they were encountered.
Source:
http://php.net/manual/en/function.curl-setopt.php#103232
In addition, if a response body is returned anywhere in the redirect chain, it will also be included in the return value of curl_exec().
So you can receive something like:
HEADER 1
HEADER 2
BODY 2
or
HEADER 1
HEADER 2
BODY 2
HEADER 3
BODY 3
Take note of this in case you only want the response header and body from the last redirect. You need to manually strip the headers and bodies from previous redirects.
You're looking at three different requests, each of which has its own set of headers. The first URL redirects to the second and the second redirects to a third. Your browser has to download three pages to get the final content of the landing page. Why do they do this? Disregard for the extra latency this adds to the user experience, mainly. Based on the URLs, this is for some kind of user tracking or statistics purpose, and it's likely easier for them to force the browser all over their site than it is to return the content directly.