I would like to know if there is a relevant http response header for the 'server generation time' ?
a delta time in ms : time taken between query reception and response send.
Following this wp page I was unable to find it..
for example : 'X-Generation-time' ?
There are no standardized header fields for that. There are probably plenty of private use names that aren't widely used or understood though. Feel free to make up your own unless you think that you might need something that other software might produce or consume.
Related
I'm working on a CGI script that will collect documents into an eBook and make that eBook easier to download.
Creating the eBook can take a few seconds, and it has timed out for some inputs for me in the past.
Is there any way I can / should keep the session alive so it doesn't time out?
Would it be helpful to add a made-up HTTP header like X-Keep-Session-Alive and periodically add a character to the header's value? (Connection: keep-alive looks like a superficially similar solution to a different problem, though I would not be completely surprised if it had something to offer me.)
(What would an implementation look like if there's anything that would do what I want?)
Is the description component of a HTTP status code used? For example, in the HTTP response '200 OK', is the OK (i.e. the description) ever used? Or is it just for humans to read?
No, the "reason phrase" is purely there for humans to read. Nothing should be using it programmatically - especially because in HTTP/2, it's been eliminated:
HTTP/2 does not define a way to carry the version or reason phrase that is included in an HTTP/1.1 status line.
The status code is often used. For example, if you are using AJAX, you will most likely check the HTTP status code before using the data returned.
However the description is just for humans as computers recognize the status code and what it entails without the description.
The description is a standard message associated with the code itself to get a quick description of the code. It is used for a diagnostic, along with its full description wich can be found on the https status code list. So, it is not "used" as i think you're implying, but indeed only used for diagnostic by humans
The data sections of messages Error, Forward and redirection responses may be used to contain human-readable diagnostic information.
I have been playing around with parsing HTTP in user-space and I see with some research that there are several ways to send data following the HTTP header and \r\n\r\n. Obviously, content-length is not always used, so what are the other methods and how do you determine the size of the data being sent before hand if not streaming?
I did see content-encoding, chunking and so on, I'm just a bit lost with the overall dynamicness of the protocol in this case. What is the sure fire way of determining the amount of data to be sent (when obviously not streaming something never ending)?
Really appreciate the help.
The new HTTP spec describes this in http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-26.html#message.body.
I am creating an app which uses sockets to send data to other devices. I am using Http protocol to send and receive data. Now the problem is, i have to stream a video and i don't know how to send a video(or stream a video).
If the user directly jump to the middle of video then how should i send data.
Thanks...
HTTP wasn't really designed with streaming in mind. Honestly the best protocol is something UDP-based (SCTP is even better in some ways, but support is sketchy). However, I appreciate you may be constrained to HTTP so I'll answer your question as written.
I should also point out that streaming video is actually quite a deep topic and all I can do here is try to touch on some of the approaches that you might want to investigate. If you have control of the end-to-end solution then you have some choices to make - if you only control one end, then your choices are more or less dictated by what's available at the other end.
If you only want to play from the start of the file then it's fairly straightforward - make a standard HTTP request and just start playing as soon as you've buffered up enough video that you can finish downloading the file before you catch up with your download rate. You don't need any special server support for this and any video format will work.
Seeking is trickier. You could take the approach that sites like YouTube used to take which is to simply not allow the user to seek until the file has downloaded enough to reach that point in the video (or just leave them looking at a spinner until that point is reached). This is not the user experience that most people will expect these days, however.
To do better you need to be in control of the streaming client. I would suggest treating the file in chunks and making byte range requests for one chunk at a time. When the user seeks into the middle of the file, you can work out the byte offset into the file and start making byte range requests from that point.
If the video format contains some sort of index at the start then you can use this to work out file offsets - so, your video client would have to request at least enough to get the index before doing any seeking.
If the format doesn't have any form of index but it's encoded at a constant bit rate (CBR) then you can do an initial HEAD request and look at the Content-Length header to find the size of the file. Then, if the use seeks 40% of the way through the video, for example, you just seek to 40% of the way through the encoded frames. This relies on knowing enough about the file format that you can calculate an appropriate seek point so that you can identify framing information and the like (or at least an encoding format which allows you to resynchonise with both the audio and video streams even if you jump in at an arbitrary point in the file). This approach might also work with variable bit rate (VBR) as long as the format is such that you can recover from an arbitrary seek.
It's not ideal but as I said, HTTP wasn't really designed for streaming.
If you have control of the file format and the server, you could make life easier by making each chunk a separate resource. This is how Apple HTTP live streaming and Microsoft smooth streaming both work. They need tool support to pre-process the video, and I don't know if you have control of the server end. Might be worth looking into, however. These also do more clever tricks such as allowing a client to switch between multiple versions of the stream encoded at different bit rates to cope with differences in bandwidth.
This is a somewhat simple question, but sadly I have not been able to find a concrete answer thus far.
We are constructing an API (we're not in production yet) which returns a large amount of data after user authentication, etc. The API system tracks the user's usage on a per second and per hour basis. When the user exceeds either of those limitations, the server returns no content and some http error code.
Presently, I'm using 406 Not Acceptable, but I don't believe that's the best code to use. Its been suggested that 509 Bandwidth Limit Exceeded would be a good one, but I wonder if there is a code which would be considered best practice for my situation. Thank you in advance for your help!
Status code 429 comes to mind:
RFC 6585, section 4: 429 Too Many Requests
The 429 status code indicates that the user has sent too many
requests in a given amount of time ("rate limiting").
The response representations SHOULD include details explaining the
condition, and MAY include a Retry-After header indicating how long
to wait before making a new request.
Well, since you've found no applicable error code, I'd guess there isn't one. In this situation, if I were you, I'd use stick with your 406 or anything like that, just decide on something and keep using it. The browser doesn't care anyway and the API's are used by people that will accept whatever code you return and deduce it's a rule - "if I exceed the usage, I get 406". I think it doesn't really matter what the magic number is.