zig icon indicating copy to clipboard operation
zig copied to clipboard

make the http client support servers that omit carriage return in http headers

Open cztomsik opened this issue 1 year ago • 3 comments

Zig Version

0.14.0-dev.1860+2e2927735

Steps to Reproduce and Observed Behavior

Add dependency to your build.zig.zon:

.url = "https://www.sqlite.org/2024/sqlite-autoconf-3450000.tar.gz"

With this I was getting:

/Users/runner/.cache/zig/p/122035cc700894b43cc5caa37b4b01492c904a10b4456189da701388b47d71ec7d4dbuild.zig.zon:15:20: error: invalid HTTP response: HttpHeadersInvalid
Error: Process completed with exit code 1.

This happened first in my github action, then after rm -rf ~/.cache/zig I replicated the issue locally. It worked before upgrading from 0.13. Either this is regression in Zig, or sqlite.org changed something (but I can't see the problem at the first sight from in curl -vvv and the file can be downloaded fine with browser/curl so I'm not sure)

Expected Behavior

should fetch the file

cztomsik avatar Oct 11 '24 19:10 cztomsik

I inspected the response from the server and noticed it is using bare LF line endings for the start line and headers, which Zig's HTTP client does not support (it supports only the standard CRLF: https://github.com/ziglang/zig/blob/008acd0547751c43f42172eab4879c566698dce3/lib/std/http/Client.zig#L461). When I did a little research to figure out which HTTP server the SQLite website uses, it appears they have their own, and just recently (October 10th) changed it to this behavior from the previous (and more correct) behavior of using CRLF: https://sqlite.org/althttpd/info/8d917cb10df3ad28

RFC 9112 says that "a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR" when parsing an HTTP message, so it may be something Zig's HTTP client should implement at some point. Still a bizarre decision by the SQLite developers (in my opinion) to change their server's behavior from what the spec mandates to something that clients may or may not support.

ianprime0509 avatar Oct 12 '24 05:10 ianprime0509

Still a bizarre decision by the SQLite developers (in my opinion) to change their server's behavior from what the spec mandates to something that clients may or may not support.

Context: https://news.ycombinator.com/item?id=41832519 and https://fossil-scm.org/forum/forumpost/2ffe0c8d6c

sgbeal avatar Oct 14 '24 00:10 sgbeal

It was reverted today: https://sqlite.org/althttpd/info/b63127980826b0bc

relapids avatar Oct 14 '24 01:10 relapids