Thu 17 Apr 2008 10:31:02 AM UTC, original submission:
Hello,
I am using wget.exe 1.11.1 from christopherlewis.com/WGet/WGetFiles.htm
When I was trying to download "MPlayer for Windows (Light-Package) " from mulder.dummwiedeutsch.de/home/?page=projects#mplayer (actually from http://mulder.dummwiedeutsch.de/home/?page=guestbook&app=mplayer&file=light-pack&mirror=somestuff ) I found this bug:
wget "http://mplayer.somestuff.org/downloads/" --post-data="file_name=MPUI.2008-04-14.Light-Package.exe&file_code=7e078c5ea4f92092d165075cdbb12b0c" -O MPUI.2008-04-14.Light-Package.exe
--2008-04-17 14:17:30-- http://mplayer.somestuff.org/downloads/
Resolving mplayer.somestuff.org... 208.113.181.146
Connecting to mplayer.somestuff.org|208.113.181.146|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 10041660 (9.6M) [application/octet-stream]
Saving to: `MPUI.2008-04-14.Light-Package.exe'
0% [ ] 9,715 24.2K/s ^
C
This works, but when am using " --content-disposition " or " -e content_disposition=on " instead of " -O MPUI.2008-04-14.Light-Package.exe " it didn't work:
--2008-04-17 14:17:37-- http://mplayer.somestuff.org/downloads/
Resolving mplayer.somestuff.org... 208.113.181.146
Connecting to mplayer.somestuff.org|208.113.181.146|:80... connected.
HTTP request sent, awaiting response... 403 Forbidden
2008-04-17 14:17:38 ERROR 403: Forbidden.
To make sure that it was not session bug I have tried to download again with " -O " and it works again.
Here is headers dump when I am using Internet Explorer 7.0 on the same page:
--- Headers Sent ---
POST /downloads/ HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, /
Referer: http://mulder.dummwiedeutsch.de/home/?page=guestbook&app=mplayer&file=light-pack&mirror=somestuff
Accept-Language: en-US
Content-Type: application/x-www-form-urlencoded
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1)
Host: mplayer.somestuff.org
Content-Length: 86
Connection: Keep-Alive
Cache-Control: no-cache
file_name=MPUI.2008-04-14.Light-Package.exe&file_code=7e078c5ea4f92092d165075cdbb12b0c
--- Headers Received ---
HTTP/1.1 200 OK
Date: Thu, 17 Apr 2008 10:08:50 GMT
Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 DAV/2 SVN/1.4.2
X-Powered-By: PHP/5.2.3
Accept-Ranges: bytes
Content-Disposition: Attachment; filename="MPUI.2008-04-14.Light-Package.exe"
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 10041660
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: application/octet-stream
(thats why I was expecting that content-disposition feature should work too)
To reproduce this bug you need to get new file_code hash from website, it is stored simply in html when you go to download page.
|