ED> I was wondering why ws_returnerror would be called without an error actually happening; more looking at debugging logs shows that it’s used for “204: Logout Successful” when ourtunes has finished its scan (which would explain why OT only dies after it’s listed my music)
Yeah, it’s really ws_return_non_200_code, or something.
ED2> Actually, a better fix would be to buffer the error message, and only send it (+ content-length header) when it’s length was known. (And do this for all errors, not just “iTunes” and “Java” user agents).
Yup, but I don’t want to buffer anything. This has to run on an asus WL-HDD, with only 16mb of ram. I don’t like the idea of buffering that stuff. At some point I’m going to have a quirks table for various user agents, like: this one only accepts keep-alives, and this one uses a single thread for streaming, etc.
In any event, I’d argue it’s breakage on the part of GiT — the headers clearly say Connection-type: Close.
I’ll add the workaround, though.
I also note that mt-daapd uses HTTP keep-alives; is it even possible to combine several keep-alive requests without having content-lengths for each of them? I can’t see how, so it might be a good idea to run through all the code and make sure they’re sent every time, to stop future similar problems…
Only by using chunked encoding, and iTunes (afaik) doesn’t honor chunked encoding. Which is too bad, as it would speed up db enumeration a lot.
As far as running through the code, my side is right. If someone chokes on it, it’s because they don’t comply with the http/1.1 spec. I’ve got plenty of bugs in this codebase, but that isn’t one of them, to my mind.
Oh, and good detective work, btw. Thanks.
— Ron