Products > Programming

Do HTTP/HTTPS servers ever enforce multipart for file downloads?

(1/3) > >>

peter-h:
I posted this elsewhere but few read that section.

So far I have managed to find out that this seems to work:

You just look for first occurence of \r\n\r\n (4 byte sequence) and then the data comes straight out, binary.

> $ telnet xxxxx.com 80
> Trying y.y.y.y...
> Connected to xxxx.com.
> Escape character is '^]'.
> GET /how/img/glide.png HTTP/1.1
> Host: xxxx.com
>
> HTTP/1.1 200 OK
> Date: Sat, 26 Aug 2023 14:10:40 GMT
> Server: Apache/2.4.41 (Ubuntu)
> Last-Modified: Sun, 06 Apr 2014 08:20:34 GMT
> ETag: "hghghghghghg"
> Accept-Ranges: bytes
> Content-Length: 7901
> Content-Type: image/png
>
> <89>PNG^Z (...)

That is easy. It would be great if one was able to avoid the multipart delimiters, because they need parsing which is messy on an embedded client; needs a bit of RAM.

Are there any standards for this stuff?

ejeffrey:
Under normal circumstances a http(s) server will not send a multipart response to a client.   Multipart is normally only used for client to server form submission with files via the POST method. 

HwAoRrDk:
The only common, standard situation I'm aware of where a server will issue a multipart response to a client is when a request has explicitly been made for multiple byte ranges using a Range header.

Other than that, I suspect an HTTP server would only do so if a specific URL was made to do so for a proprietary purpose. You're highly unlikely to encounter that in the wild though. In fact, I suspect such a server would only give you a multipart response if you gave it an Accept header containing multipart/* (or something more specific).

golden_labels:
A multipart response doesn’t require more memory to process than any other response, in practical terms. I’d say this renders the entire question dismissible.

A server may respond with multipart data. Realistically this is only going to happen if you already expect receiving a multipart response. HTTP services may be roughly divided into two groups: these meant for web browsers, and API endpoints. So we deal with the following scenarios:
* A browser making a simple request for normal content:
The browser expects a single object in response and it makes no sense for a server to send multiple objects. Browsers couldn’t even handle that.
* A browser makes a request to a dynamically changing resource:
Primarily to webcams sending low framerate images stream over HTTP. The response is realized over multipart/x-mixed-replace. You must make a request to that kind of a resource to receive a multipart response.
* A client makes a request for multiple byte ranges:
Aside from not very wide adoption of this feature, the client must make an explicit request for multipart data. Which implies it expects the multipart response and can handle it.
* API endpoints:
Rarely encountered, but possible. If you make a request to a particular API endpoint, you already know what kind of response you are going to receive. So a multipart response is possible only, if you already wanted one.Making a plain request without expecting multipart data and recieving a multipart response would be more than weird.

peter-h:
Thank you all. This has been extremely interesting and useful!

Navigation

[0] Message Index

[#] Next page