HTTP 1.1 responses can be chunked (spec). At the end of the last chunk the server can send a "trailer", which contains additional headers.
The question is: can you include a Location header in the trailer, and will the browser react by making a redirect?
The problem is that Location header to work should be with specific response code 3xx so in a standard response you can't use it see http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Yes.
To have the Location header, the server should be responding with the 201 or one of the 3XX status codes. It should also include content, perhaps a message in HTML explaining what happened and giving a handy hyperlink to the resource. The content would need to be chunked and the Transfer-Encoding header should be present and have the value "chunked".
If all this were true, then the Trailer header could be added with a value of "Location", and the Location header could then trail the content.
Here's the real issue: This seems silly and pointless. What use case might you have where you will redirect a client to a new location, yet you don't know that location until after the content is complete? I can't think of a reason. But maybe you have one? If there's not a good use case, then I don't think you should do this.
Edit: I thought of a reason. Shiflett gives an example of chunked transfer encoding where the first chunk of HTML sent to the client says, "We are completing your transaction." Time passes while the transaction is completed. Then the second and final chunk of HTML is sent to the client that says, "Ok, your transaction is now complete." (HTTP Dev's Handbook p97) Combine this idea with a 201 where a new file is created. It might be that the location of the new file is unknown until the very end of the server's processing. Thus it would want to use chunked transfer encoding, and it would want to put the Location header in the trailers.
Second Edit: Yes, you can add it because the spec specifically forbids only the following header fields: Transfer-Encoding, Content-Length, and Trailer.
Related
I want to send large amount of json over http to sever.
If I use "Content-Encoding":"GZIP" in my httpClient, does it automatically convert the request body to compressed format?
No, the RFC 7231 describes content encoding. If you are sending Content-Encoding you need to make sure that the content is in that encoding.
If you send Content-Encoding: gzip and the message in plain text you will (quite rightly) receive an HTTP 400. The body of a gzip message will always start with 0x1f 0x8b and if the server does not find that int he POST request it is right to complain.
Another reason for this is that you need an appropriate Content-Length header. This will not be the length of the original JSON, it must be the length (in bytes) of the gzipped JSON.
You need to perform the gzip of the JSON before sending anything since you need to know what to place in Content-Length beforehand.
Extra note: If the JSON is that huge (e.g. several gigabytes) you probably will need Transfer-Encoding: chunked, which comes with its own complications. (You do not send Content-Length but add the length of the chuck to the body itself.)
If it automatically does this, is 100% dependent on which http client you are using and if they implemented it that way. Usually setting a header will not automatically encode it, at least in the clients I regularly use.
What status code should be returned if a client sends an HTTP request and specifies a Content-Encoding header which cannot be decoded by the server?
Example
A client POSTs JSON data to a REST resource and encodes the entity body using the gzip coding. However, the server can only decode DEFLATE codings because it failed the gzip class in server school.
What HTTP response code should be returned? I would say 415 Unsupported Media Type but it's not the entity's Content-Type that is the problem -- it's the encoding of the otherwise supported entity body.
Which is more appropriate: 415? 400? Perhaps a custom response code?
Addendum: I have, of course, thoroughly checked rfc2616. If the answer is there I may need some new corrective eyewear, but I don't believe that it is.
Update:
This has nothing to do with sending a response that might be unacceptable to a client. The problem is that the client is sending the server what may or may not be a valid media type in an encoding the server cannot understand (as per the Content-Encoding header the client packaged with the request message).
It's an edge-case and wouldn't be encountered when dealing with browser user-agents, but it could crop up in REST APIs accepting entity bodies to create/modify resources.
As i'm reading it, 415 Unsupported Media Type sounds like the most appropriate.
From RFC 2616:
10.4.16 415 Unsupported Media Type
The server is refusing to service the request because the entity of the request is in a format not supported by the requested resource for the requested method.
Yeah, the text part says "media type" rather than "encoding", but the actual description doesn't include any mention of that distinction.
The new hotness, RFC 7231, is even explicit about it:
6.5.13. 415 Unsupported Media Type
The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated
Content-Type or Content-Encoding, or as a result of inspecting the
data directly.
They should make that the final question on Who Wants To Be a Millionaire!
Well the browser made a request that the server cannot service because the information the client provided is in a format that cannot be handled by the server. However, this isn't the server's fault for not supporting the data the client provided, it's the client's fault for not listening to the server's Acccept-* headers and providing data in an inappropriate encoding. That would make it a Client Error (400 series error code).
My first instinct is 400 Bad Request is the appropriate response in this case.
405 Method Not Allowed isn't right because it refers to the HTTP verb being one that isn't allowed.
406 Not Acceptable looks like it might have promise, but it refers to the server being unable to provide data to the client that satisfies the Accept-* request headers that it sent. This doesn't seem like it would fit your case.
412 Precondition Failed is rather vaguely defined. It might be appropriate, but I wouldn't bet on it.
415 Unsupported Media Type isn't right because it's not the data type that's being rejected, it's the encoding format.
After that we get into the realm of non-standard response codes.
422 Unprocessable Entity describes a response that should be returned if the request was well-formed but if it was semantically incorrect in some way. This seems like a good fit, but it's a WebDAV extension to HTTP and not standard.
Given the above, I'd personally opt for 400 Bad Request. If any other HTTP experts have a better candidate though, I'd listen to them instead. ;)
UPDATE: I'd previously been referencing the HTTP statuses from their page on Wikipedia. Whilst the information there seems to be accurate, it's also less than thorough. Looking at the specs from W3C gives a lot more information on HTTP 406, and it's leading me to think that 406 might be the right code after all.
10.4.7 406 Not Acceptable
The resource identified by the request is only capable of generating
response entities which have content characteristics not acceptable
according to the accept headers sent in the request.
Unless it was a HEAD request, the response SHOULD include an entity
containing a list of available entity characteristics and location(s)
from which the user or user agent can choose the one most appropriate.
The entity format is specified by the media type given in the
Content-Type header field. Depending upon the format and the
capabilities of the user agent, selection of the most appropriate
choice MAY be performed automatically. However, this specification
does not define any standard for such automatic selection.
Note: HTTP/1.1 servers are allowed to return responses which are
not acceptable according to the accept headers sent in the
request. In some cases, this may even be preferable to sending a
406 response. User agents are encouraged to inspect the headers of
an incoming response to determine if it is acceptable.
If the response could be unacceptable, a user agent SHOULD temporarily
stop receipt of more data and query the user for a decision on further
actions.
While it does mention the Content-Type header explicitly, the wording mentions "entity characteristics", which you could read as covering stuff like GZIP versus DEFLATE compression.
One thing worth noting is that the spec says that it may be appropriate to just send the data as is, along with the headers to tell the client what format it's in and what encoding it uses, and just leave it for the client to sort out. So if the client sends a header indicating it accepts GZIP compression, but the server can only generate a response with DEFLATE, then sending that along with headers saying it's DEFLATE should be okay (depending on the context).
Client: Give me a GZIPPED page.
Server: Sorry, no can do. I can DEFLATE pack it for you. Here's the DEFLATE packed page. Is that okay for you?
Client: Welllll... I didn't really want DEFLATE, but I can decode it okay so I'll take it.
(or)
Client: I think I'll have to clear that with my user. Hold on.
I am working on an existing Silverlight file uploader that breaks files into multiple chunks and transmits the file using multiple HTTP requests.
Currently, it sends the start and total byte information on the querystring, but as learning exercise, I'd like to use a more standards-based approach.
I've previously used the HTTP Content-Range header when implementing an endpoint that serves content. Is this header also appropriate to use when posting content from a client to the server?
Yes.
RFC 2616 (HTTP 1.1), Section 14 begins by stating:
For entity-header fields, both sender and recipient refer to either
the client or the server, depending on who sends and who receives the
entity.
Other than that, Section 14.16, which defines the Content-Range header, does not appear to contain any language limiting its use to either the request or response.
Probably not, at least as of 2014 (the original answer is from 2011).
The updated HTTP 1.1 specification, rfc7231 (4.3.3), says the following about valid POST responses:
An origin server indicates response semantics by choosing an
appropriate status code depending on the result of processing the
POST request; almost all of the status codes defined by this
specification might be received in a response to POST (the exceptions
being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
Satisfiable)).
Given that this language was explicitly added to the updated spec, I doubt the authors intended that the Content-Range header be used with the POST method.
What is the correct response to a GET request with the header field Range: bytes=278528- if Range is not supported?
Reading the HTTP header definitions (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html) i think i should at least set: Accept-Ranges: none, but it clearly states that
Clients MAY generate byte-range requests without having received this header for the resource involved.
So, if a client requests a range, should I:
Reply with the whole file from byte 0?
Reply with some status error? (400/406/416/501) see: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
You may ignore it, as the spec says. To be precise:
If you support it, you return a status code of 206 Partial Content and include the proper headers like Content-Range.
If you don’t support it, you return a 200 OK as normal.
I have not tested this, but the spec seems pretty clear. I have seen this work — using wget or curl to resume an interrupted download will properly restart from the beginning if the server does not support the Range header.
RFC2616 section 14.35.2 says:
A server MAY ignore the Range header.
The possibility is check the http header and if there is a range string, parse it, parse to ranges, compute skip and take positions, open file stream from url, then, seek to skip and take 'take ' bytes, setup response of it, send response and finaly close stream.
do not forget to respond with range header
do not ignore range, never when you are working on big streams.
if you are using nanohttp, i can help you out with example
Ignoring range requests can made play content (which is huge) on airplay service or another unstable or unacceptable. I know that http is not right protokol to transfer video, but try to send video to airplay from server not accepting ranges....
Airplay uses range requests...
I request a website header, however, there is not Last-Modified info in this http header. I wanna creat a site map and get each file's date on the server. Don't understand why there is not this info for some websites. How did some softwares, such as Xenu, get the file's date.
As Johannes Rössel points in his comment to your question, the Last-Modified header is not compulsory. If it is there, you can read it just like any other HTTP header (the exact method depends on your exact code so we can't say more until there's code). If it isn't there, you can't read it. It's as simple as that. You can't fetch information about remote resources unless the remote server provides such piece of info. That's valid for HTTP and most other network protocols.