Okay, i encountered this bug when grip (linked against libghttp) failed to download some album info. I used ethereal to capture the corresponding packages, and noticed that libghttp has an incredible stupid bug: It uses your current locale for the http version number! It did indeed specify "HTTP/1,1" instead "HTTP/1.1". And sometimes (not always) apache then responds with a 400, in my case resulting in the failed freedb query. The workaround is of course easy: #> export LC_LOCALE="en" Doing some research it seems like libghttp is no longer developed. No changes for years, i can only wonder why, since this bug is simply too obvious. But i think debian stable uses a patched version, so it shouldn't be too difficult to use that patch in gentoo, too. Greetings and thanks for the great work! Reproducible: Always Steps to Reproduce: 1. use libghttp with LC_NUMERIC="de" (for example) Actual Results: wonder about the wrong HTTP protocol version delimiter (in this case a comma). Expected Results: it should always be HTTP/1.1 root@hal:~# emerge -pv libghttp These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] gnome-base/libghttp-1.0.9-r3
Sorry, the workaround is of course #> export LC_NUMERIC="en" and not #> export LC_LOCALE="en" And i'll post an article in the forum explaining this workaround for other users encountering this bug.
I'm at least as stupid as this bug, and very sorry, but "en" is of course *no* valid locale string, you should of course use "en_US" or sth.
got a patch by any chance ? (diff -uN preferably)
ok i found a patch somewhere and added it to libghttp-1.0.9-r4, please update and test if it fixes your problems ? This would be seriously faster handled if you had also provided the patch, please try to help us out as much as possible. Don't just describe the problem, but also provide the patch you are talking about.
I tested it, and the patch fixes the problem. And the patch itself looks good, too. I'm also sorry about not providing the patch with the bug report, i'll try to do that next time. Especially since i had one around (although that one included more changes).
I wonder if 1.0.9-r4 couldn't be marked stable for x86, especially since it already has been for sparc and alpha and there's only minimal change.
noted.. stable x86 now