When I click on a binary file (image files, PDF files, videos files etc) in a browser to download, does the server return these files in an HTTP response body? Does HTTP protocol support binary HTTP response body in the first place? Or does the browser uses some other protocol internally to transfer these files?
Any reference (books, links) on how browser works would be appreciated!
Does HTTP protocol support binary HTTP response body in the first place?
Yes. I believe the browser knows it is binary because of the Content-Type header in the response.
In the image below, captured from Wireshark, the data highlighted in blue is binary.
You can see this data is in the body of the response of an HTTP request for an image/x-icon.
Related
Today, HTTP headers all need to be sent before a single bit of HTTP body is sent to the browser.
This is especially problematic with new technologies such as React 18 Streaming where certain headers, such as caching headers and 103 Early Hints, can be determined with certainty only at the end of the HTTP stream. Ideally these late headers would be sent to the browser just before ending the stream.
Are there efforts from spec working groups or browser vendors to enable headers to be sent during/after the HTTP body?
After doing research, it seems that there is no spec work about this, but I wonder if there is a browser vendor working on this? (Some browser folks are active here on StackOverflow.)
Context: I'm the author of vite-plugin-ssr and react-streaming.
There is a specification for Trailer fields for use with Chunked Encoding (Http 1.1, https://httpwg.org/specs/rfc7230.html#header.trailer).
The HTTP2 spec (which does not support Chunked Encoding) directly allows for a headers frame following the Data frames that contain the http body https://datatracker.ietf.org/doc/html/rfc7540#section-8.1.
Library support may vary as most http libraries attempt to abstract away the differences in the underlying protocols. In Javascript you will be interested in enabling trailing headers in the cross-browser standard fetch API. The MDN docs suggest that support is coming with reference to a trailers field on the Response object: https://developer.mozilla.org/en-US/docs/Web/API/Response.
I am serving binary data through http.
For the time being I use Content-Disposition: attachment.
Can I use the built in http compression (having the client request data with the header Accept-Encoding) to compress the attachment?
Or should I compress the attachment manually?
What is the proper way of serving compressed byte arrays through http?
Content-disposition is merely a header instructing the browser to either render the response, or to offer it as a download to the user. It doesn't change any HTTP semantics, and it doesn't change how the response body is transferred or interpreted.
So just use the built-in compression that compresses the response body according to the request header Accept-encoding.
I've been looking at how to implement an API over HTTP that allows for online processing of the resource it returns. This resource could be a progressive JPEG, for example. In reading up on progressive JPEGs and how they are rendered in browsers I never see any mention of this requiring chunked transfer encoding to work. If I'm understanding things correctly I don't see how progressive JPEGs could be rendered before they are fully downloaded without the use of chunked transfer encoding. Is this correct?
Edit: To clarify why I think chunked encoding is needed if you don't use chunked encoding to GET a progressive JPEG then the browser or other application that sent the GET request for the JPEG wouldn't be passed the JPEG resource until it was fully received. With chunked encoding, on the other hand, as each chunk of the JPEG came in, the application (browser or otherwise) could render or do whatever with the portion of the JPEG that was received instead of not having anything to process until the full JPEG was downloaded.
the browser or other application that sent the GET request for the JPEG wouldn't be passed the JPEG resource until it was fully received
That's not true. Browsers can access resources they are downloading before the download completes.
In the end it's all received over a socket, and a proper abstraction layer lets the application code "stream" bytes from that socket as they come in in packets.
I want to know the exact mechanism behind the transfer of binary files using a browser. If the browser uses purely HTTP that means only text is allowed so the image is encoded using base64 and decoded later in browser? Or does the browser download this using some other mechanism where this encoding/decoding is not needed?
Just in case someone wants to know the answer. While you can send the binary data over HTTP using base64 encoding, it is not the most efficient process, as encoding and decoding is required. So when you request an image file using http, the server gives you the metadata information such as MIME type, content-length etc. Using this information, the HTTP agent (eg. browser) actually downloads the image directly using TCP and not HTTP.
Is there any way sending video (binary data) over HTTP?
I read that HTTP multipart request is used for that.
The problem is that when the client starts sending the clip, it doesn't have the entire video yet (still been captured by the camera). The client sends frame by frame.
Does multipart request is good for sending video before all clip is available?
Thanks.
What you are looking for is a streamable container format. The most popular today are Apples HTTP Live Streaming, and fragmented mp4 (usually called DASH)
There is no problem sending binary data over HTTP, and no, you don't need multipart formats for that.