Bug 139926 - re-introduced parsing & bug in wget
Summary: re-introduced parsing & bug in wget
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: wget
Version: 2
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Karsten Hopp
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-18 19:58 UTC by Bill
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-12-13 12:34:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Bill 2004-11-18 19:58:57 UTC
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

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