Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: Unknown Content-Encoding value and zero-lenght string CURLOPT_ACCEPT_ENCODING
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Fujii Hironori via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 29 Oct 2021 10:10:42 +0900
On Thu, Oct 28, 2021 at 8:15 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Thu, 28 Oct 2021, Fujii Hironori via curl-library wrote:
>
> > Monaco Editor Samples is using their own HTTP server 'yaserver' which
> sends
> > an invalid 'Content-Encoding: utf8' header.
>
> Shouldn't you then report this as an error against yaserver?
>
I did it. https://github.com/alexdima/yaserver/issues/2
>
> > However, if I invoke curl commnad with '--compressed' switch, it reports
> > 'CURLE_BAD_CONTENT_ENCODING' error.
>
> It's not a known encoding to libcurl.
>
> >
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding>
> > 'identity' value "is always considered as acceptable, even if omitted."
>
> The better reference for the header is here:
> https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.2.2
>
> > Why doesn't curl treat the unknown encoding as identity if
> > CURLOPT_ACCEPT_ENCODING is set to ""?
>
> I don't think that's what it says we should do, because that would then
> also
> pass on contents compressed with other algorithm than what curl supports
> etc.
>
> But I understand what you're asking for. Maybe we should provide a way to
> tell
> libcurl "when no matching encoding is found, pretend it was identity". Of
> course that will then risk passing on complete garbage at times.
>
That's an option I want.
Major browsers can load the response. Minor browsers should follow the
behavior.
The behavior of major implementations is more important than RFC for me.
>
> > Should WinCairo set the CURLOPT_ACCEPT_ENCODING explicitly to the
> following
> > instead of "" ?
> >
> >> curl_easy_setopt(m_handle, CURLOPT_ACCEPT_ENCODING, "identity, deflate,
> > gzip, br");
>
> That list still doesn't include 'utf8'.
>
My bad, it was my mistake. Specifying 'identity' doesn't make curl ignore
unknown encodings.
On Thu, Oct 28, 2021 at 10:11 PM Philip Tellis via curl-library <
curl-library_at_lists.haxx.se> wrote:
> I think curl is doing the right thing. If the compressed flag is set, then
> curl has to decode the encoding itself. If the flag isn't set then curl
> passes that responsibility to the calling application.
>
> This allows applications to use curl as a transport.
>
>
That means I have to set CURLOPT_HTTPHEADER and decode br, gzip and deflate.
https://curl.se/libcurl/c/CURLOPT_ACCEPT_ENCODING.html also says do so.
But, it's too complicated.
Date: Fri, 29 Oct 2021 10:10:42 +0900
On Thu, Oct 28, 2021 at 8:15 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Thu, 28 Oct 2021, Fujii Hironori via curl-library wrote:
>
> > Monaco Editor Samples is using their own HTTP server 'yaserver' which
> sends
> > an invalid 'Content-Encoding: utf8' header.
>
> Shouldn't you then report this as an error against yaserver?
>
I did it. https://github.com/alexdima/yaserver/issues/2
>
> > However, if I invoke curl commnad with '--compressed' switch, it reports
> > 'CURLE_BAD_CONTENT_ENCODING' error.
>
> It's not a known encoding to libcurl.
>
> >
> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding>
> > 'identity' value "is always considered as acceptable, even if omitted."
>
> The better reference for the header is here:
> https://datatracker.ietf.org/doc/html/rfc7231#section-3.1.2.2
>
> > Why doesn't curl treat the unknown encoding as identity if
> > CURLOPT_ACCEPT_ENCODING is set to ""?
>
> I don't think that's what it says we should do, because that would then
> also
> pass on contents compressed with other algorithm than what curl supports
> etc.
>
> But I understand what you're asking for. Maybe we should provide a way to
> tell
> libcurl "when no matching encoding is found, pretend it was identity". Of
> course that will then risk passing on complete garbage at times.
>
That's an option I want.
Major browsers can load the response. Minor browsers should follow the
behavior.
The behavior of major implementations is more important than RFC for me.
>
> > Should WinCairo set the CURLOPT_ACCEPT_ENCODING explicitly to the
> following
> > instead of "" ?
> >
> >> curl_easy_setopt(m_handle, CURLOPT_ACCEPT_ENCODING, "identity, deflate,
> > gzip, br");
>
> That list still doesn't include 'utf8'.
>
My bad, it was my mistake. Specifying 'identity' doesn't make curl ignore
unknown encodings.
On Thu, Oct 28, 2021 at 10:11 PM Philip Tellis via curl-library <
curl-library_at_lists.haxx.se> wrote:
> I think curl is doing the right thing. If the compressed flag is set, then
> curl has to decode the encoding itself. If the flag isn't set then curl
> passes that responsibility to the calling application.
>
> This allows applications to use curl as a transport.
>
>
That means I have to set CURLOPT_HTTPHEADER and decode br, gzip and deflate.
https://curl.se/libcurl/c/CURLOPT_ACCEPT_ENCODING.html also says do so.
But, it's too complicated.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2021-10-29