Bugzilla Bug 33386

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