Harry Sintonen

I can confirm that 0xe71 is the correct offset and I can now successfully unlock such system.

I'd also note that the issue of failing to parse very long URLs properly might also have a security impact: For example if a security critical code would use http_parser_parse_url...

I think this would be more suitable for some generic curl discussion instead of a bug ticket.

There is still insufficient information to be able to help, really. Either way, I find it exceedingly unlikely this would be a bug in curl.

OpenXLSX uses locale aware routines elsewhere to format floats. Hence it itself generates invalid formats. Either you consistently obey locale or don't. You can't mix.

Here are steps to reproduce: 1. Apply this patch: ```diff --git a/Examples/Demo1.cpp b/Examples/Demo1.cpp index 44d6eee..102b571 100644 --- a/Examples/Demo1.cpp +++ b/Examples/Demo1.cpp @@ -7,6 +7,8 @@ using namespace OpenXLSX; int main() {...

This is a bit messy to fix cleanly on all platforms. On `POSIX 2008` conforming system this is somewhat ok, as you can `newlocale` the `"C"` locale, and then either...

Ok that works at least in initial tests. I also had to defer `Curl_dyn_reset(&data->state.headerb);` to occur only after the `Curl_client_write()` call.

Just moving the `Curl_dyn_reset` later is wrong though, at least when considering the comment at https://github.com/curl/curl/blob/1c4813c769ea65c128c067004d0711433288aa05/lib/http.c#L3663 I tried creating a dynbuf copy of the hd, hdlen data and then doing...

> Is there valid input which can produce an empty string be returned from utf8asn1str() here? That's beside the point. The original fix was for scenario that didn't happen anyway,...