Open astares opened 9 months ago
Well, the accept header value is not necessarily a mime type but a mime type list. So I don't expect that ZnMimeType can parse the header value. For the other class I don't know.
On Thu, Feb 8, 2024, 12:50 Astares @.***> wrote:
see https://www.geeksforgeeks.org/http-headers-accept/
— Reply to this email directly, view it on GitHub https://github.com/pharo-project/pharo/issues/16122#issuecomment-1934415082, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQCK6AX4AANWVMNEZQ5KX3YSTX3TAVCNFSM6AAAAABC77HLKKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZUGQYTKMBYGI . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Interesting, like @gcotelli says, it is a list (or a multi-valued header).
You could parse this as follows:
input := 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
'.
($, split: input) collect: [ :each | each asMIMEType ]
But there is indeed a problem in how this is handled further on (it is assumed to be single valued, probably because that was good enough at the time).
I remember vaguely that I once did something with these q (qualities), but I can't find it anymore.
I will think about this a bit more.
Typically in HTTP there is an accept header to communicate about the mime types the client would accept.
When I get a client request from a browser the ACCEPT header part for a simple GET typically looks like this:
for Chrome.
When I use
or
the info about the images is lost
I'm not too deep in the RFCs - maybe @svenvc knows more