Re: [Bug-wget] Problem with --content-disposition, HTTP/FTP connection not reused
Zitat von Jochen Roderburg roderb...@uni-koeln.de: Zitat von Ángel González keis...@gmail.com: Jochen Roderburg wrote: This looks like the same issue I decribed recently here: wget makes a HEAD request first, and the reply-headers do not contain a Content-Disposition header. The Content-Disposition header comes then on the subsequent GET request, but wget seems to ignore it there. Regards, Jochen Roderburg Confirmed. Running wget --timestamp -S --content-disposition http://example.com and giving the Content-Disposition header just on GET, gives the above result. Precisely, that is the combination of options which triggers the effect in recent wget 1.13.x versions because --timestamp=on forces the HEAD requests. Older versions with Content-Disposition support (like the 1.11.4 which the OP reported) made *always* HEAD requests with --content-disposition=on alone and had this error then also always. Regards, Jochen Roderburg Hi Mark, Just an additional remark what this findings now mean for your original question: You *can't* avoid the problem with your wget version 1.11.4, but you usually *can* avoid it with newer 1.13.x versions. Regards, Jochen Roderburg
Re: [Bug-wget] Problem with --content-disposition, HTTP/FTP connection not reused
Zitat von Ángel González keis...@gmail.com: Jochen Roderburg wrote: This looks like the same issue I decribed recently here: wget makes a HEAD request first, and the reply-headers do not contain a Content-Disposition header. The Content-Disposition header comes then on the subsequent GET request, but wget seems to ignore it there. Regards, Jochen Roderburg Confirmed. Running wget --timestamp -S --content-disposition http://example.com and giving the Content-Disposition header just on GET, gives the above result. Precisely, that is the combination of options which triggers the effect in recent wget 1.13.x versions because --timestamp=on forces the HEAD requests. Older versions with Content-Disposition support (like the 1.11.4 which the OP reported) made *always* HEAD requests with --content-disposition=on alone and had this error then also always. Regards, Jochen Roderburg
Re: [Bug-wget] Problem with --content-disposition, HTTP/FTP connection not reused
Hi, Ángel González wrote: The second issue is that the --content-disposition option doesn't seem to work, at least not for the https URL I tried: $ wget -S --content-disposition https://fp-pr1.ds.microsoft.com/TransferFile/FileTransfer.dll?Cmd=1MN=1234567890Dir=1Mode=0Off=0TS=-1ACD-4945-BCD6-DDAFE738ECB3CVN=5,0,0,32; Those urls have expired, but I made a quick test script (with http), and it worked. I neglected to mention that I munged the URL in the example in case it contained info related to my login ID. If you want to test downloading files from that site specifically: Log into http://connect.microsoft.com Go to https://connect.microsoft.com/site148/Downloads/DownloadDetails.aspx?DownloadID=21028 Click one of the download links at the bottom. As your browser is downloading the file, right-click the downloading file and choose copy link location, then use that URL with wget. (That procedure works in Firefox.) -- Mark
Re: [Bug-wget] Problem with --content-disposition, HTTP/FTP connection not reused
On 16/10/11 22:33, markk wrote: Hi, I'm writing to report a couple of issues with wget (version 1.11.4, so apologies if either has been fixed recently). The first issue is that wget doesn't seem to reuse the HTTP or FTP connection when multiple URLs (to the same site) are given on the command line, e.g. $ wget ftp://site.example.com/path1/file1.bin ftp://site.example.com/path2/file2.bin It is reused here (1.13.4) with http, but not with ftp. The second issue is that the --content-disposition option doesn't seem to work, at least not for the https URL I tried: $ wget -S --content-disposition https://fp-pr1.ds.microsoft.com/TransferFile/FileTransfer.dll?Cmd=1MN=1234567890Dir=1Mode=0Off=0TS=-1ACD-4945-BCD6-DDAFE738ECB3CVN=5,0,0,32; Those urls have expired, but I made a quick test script (with http), and it worked.
Re: [Bug-wget] Problem with --content-disposition, HTTP/FTP connection not reused
Zitat von ma...@clara.co.uk: The second issue is that the --content-disposition option doesn't seem to work, at least not for the https URL I tried: $ wget -S --content-disposition https://fp-pr1.ds.microsoft.com/TransferFile/FileTransfer.dll?Cmd=1MN=1234567890Dir=1Mode=0Off=0TS=-1ACD-4945-BCD6-DDAFE738ECB3CVN=5,0,0,32; --2011-10-16 21:05:06-- https://fp-pr1.ds.microsoft.com/TransferFile/FileTransfer.dll?Cmd=1MN=1234567890Dir=1Mode=0Off=0TS=-1ACD-4945-BCD6-DDAFE738ECB3CVN=5,0,0,32 Resolving fp-pr1.ds.microsoft.com... 65.54.120.201 Connecting to fp-pr1.ds.microsoft.com|65.54.120.201|:443... connected. HTTP request sent, awaiting response... HTTP/1.1 200 OK Content-Length: 342 Content-Type: text/html Server: Microsoft-IIS/7.5 ServerVersion: 5, 0, 0, 42 FTMException: 22073 FTMExceptionText: ule: CFileTransferIsapi.cpp, Line#: 232 Debug Text: General Application Error Context Text: CFileTransferIsapi::Run Command:CMD is invalid FTMClass: FTMClassText: X-Powered-By: ASP.NET Date: Sun, 16 Oct 2011 20:05:07 GMT Connection: keep-alive Length: 342 [text/html] --2011-10-16 21:05:07-- https://fp-pr1.ds.microsoft.com/TransferFile/FileTransfer.dll?Cmd=1MN=1234567890Dir=1Mode=0Off=0TS=-1ACD-4945-BCD6-DDAFE738ECB3CVN=5,0,0,32 Reusing existing connection to fp-pr1.ds.microsoft.com:443. HTTP request sent, awaiting response... HTTP/1.1 200 OK Content-Length: 86751232 Content-Type: application/octet-stream Expires: -11 Server: Microsoft-IIS/7.5 ServerVersion: 5, 0, 0, 42 SPTransferStatus: Content-Disposition: inline; filename=winddk.rtm.iso X-Powered-By: ASP.NET Date: Sun, 16 Oct 2011 20:05:08 GMT Connection: keep-alive Length: 86751232 (83M) [application/octet-stream] Saving to: `FileTransfer.dll?Cmd=1MN=1234567890Dir=1Mode=0Off=0TS=-1ACD-4945-BCD6-DDAFE738ECB3CVN=5,0,0,32' -- Mark This looks like the same issue I decribed recently here: wget makes a HEAD request first, and the reply-headers do not contain a Content-Disposition header. The Content-Disposition header comes then on the subsequent GET request, but wget seems to ignore it there. Regards, Jochen Roderburg
Re: [Bug-wget] Problem with --content-disposition, HTTP/FTP connection not reused
Jochen Roderburg wrote: This looks like the same issue I decribed recently here: wget makes a HEAD request first, and the reply-headers do not contain a Content-Disposition header. The Content-Disposition header comes then on the subsequent GET request, but wget seems to ignore it there. Regards, Jochen Roderburg Confirmed. Running wget --timestamp -S --content-disposition http://example.com and giving the Content-Disposition header just on GET, gives the above result.
