Description of problem: wget does not parse & in a URL. It was fixed at one point, years back. (wget-1.7-1) Version-Release number of selected component (if applicable): wget-1.9.1-16.fc2, wget-1.9+cvs-stable, others How reproducible: Always Steps to Reproduce: wget -options "http://some.web.site/script?option1=1&option2=2" -O file Actual Results: --00:00:00-- http://some.web.site/script?option1=1&option2=2 => `file' Connecting to some.web.site... connected. HTTP request sent, awaiting response... 400 Bad Request 14:30:31 ERROR 400: Bad Request. Reference: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=39985
This is not a bug. Escaping HTML entities is something that should happen only when wget is parsing HTML. URL given on the command line is not HTML so it is correct behavior to send the URL to the server as given on the command line. To show that wget is not expanding entities correctly you'd need to make a HTML file, put an a href tag in it (with &) and grab wget with -r option to see whether wget will visit the correct URL. I just tried this with GNU Wget 1.9+cvs-stable (Red Hat modified) and it expands entities properly. I suggest to close this as NOTABUG.