Bug 139926 - re-introduced parsing & bug in wget
re-introduced parsing & bug in wget
Product: Fedora
Classification: Fedora
Component: wget (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: Karsten Hopp
Depends On:
  Show dependency treegraph
Reported: 2004-11-18 14:58 EST by Bill
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-13 07:34:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill 2004-11-18 14:58:57 EST
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:

Steps to Reproduce:
wget -options "http://some.web.site/script?option1=1&option2=2" -O

Actual Results:
--00:00:00--  http://some.web.site/script?option1=1&option2=2 =>
Connecting to some.web.site... connected.
HTTP request sent, awaiting response... 400 Bad Request
14:30:31 ERROR 400: Bad Request.

Comment 1 Branimir Dolicki 2004-12-13 05:30:53 EST
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.

Note You need to log in before you can comment on or make changes to this bug.