RE: Syntax question ...
On Thu, 22 Jan 2004, Simons, Rick wrote: curl https://server/file -uuser:pass Virtual user user logged in. No file created locally. Chalk it up as a http server flaw? Uh, curl doesn't create any file when used like that. It outputs the downloaded data to stdout unless you use an option to direct it elsewhere. You can use curl -v -i [URL] to get to see the full request curl sends and all the headers it receives back. Then those could be compared to what wget sends/gets. In my eyes, this looks like the correct output from curl. Wasn't it? -- -=- Daniel Stenberg -=- http://daniel.haxx.se -=- ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
post-data option problems
Hello, I seem to be having problems with the post-data option of wget on a specific website. I'm trying to automate the download of this website: http://mospublic.ercot.com/ercot/jsp/midterm_load_forecast.jsp The difficulty is that the website contains data on multiple pages accessible through a drop-down menu which submits a post on change. Ultimately I want to access each of the market dates in the drop-down menu, but I cant seem to access any other page other than the default page (the current date) using wget. I've tried: wget http://mospublic.ercot.com/ercot/jsp/midterm_load_forecast.jsp \ --post-data=marketdate=2004-01-22scrollsize=24 -O midloadforcast040122.html (where today's date is the 23rd and I want to access the data on the 22nd) The odd thing is that the scroll size did update properly, yet the market date did not. I also attempted placing all the variables in the url and avoided using post-data with the same results, the scroll size would work fine, but the market date would still be the current date. Although if I place the url (http://mospublic.ercot.com/ercot/jsp/midterm_load_forecast.jsp?marketda te=2004-01-20 http://mospublic.ercot.com/ercot/jsp/midterm_load_forecast.jsp?marketda te=2004-01-20scrollsize=20 scrollsize=20) into a browser, it returns the correct page and data. The command I used was: wget http://mospublic.ercot.com/ercot/jsp/midterm_load_forecast.jsp?marketda te=2004-01-20scrollsize=20 -O midloadforcast040120.html I even tried using Curl, and the results were the same, therefore I assume it has something to do with how the jsp server processes the request? I'm using the windows 1.9.1 binary of wget. Is there anything I can do? And could the replies be cc to me, since I'm not subscribed to the mailing list. Thank you, Dan
mms:// URLs
Is there any future plan to include support for mms:// URLs in wget? Or any command-line Linux utility that can download mms:// URLs? (mms:// is streaming multimedia files; I'd like to be able to download the entire file.)
Re: Syntax question ...
Daniel Stenberg [EMAIL PROTECTED] writes: On Thu, 22 Jan 2004, Simons, Rick wrote: curl https://server/file -uuser:pass Virtual user user logged in. [...] In my eyes, this looks like the correct output from curl. Wasn't it? I think that Rick expects to see a complete HTML page rather than the Virtual user X logged in message. Both Wget and curl exhibit the incorrect output. Rick, if you are inclined to fiddle some more with this, another possibility would be to trace the communication between a browser where the page works and the web server. Since trace and tcpdump don't play well with SSL, the easiest way (I'm aware of) to accomplish this is using something like the liveheaders Mozilla extension; get it from http://livehttpheaders.mozdev.org/. Specifically, use livehttpheaders to see what headers Mozilla was sending, and use Wget's `--header' option to send out the same request. See if things work then. If not, it might be useful to compare the response in both cases. If things fail with Wget again, then the next thing to blame would be OpenSSL... it might be useful to see if *any* OpenSSL-using browser (e.g. `links' or `lynx') can display the page correctly.
Re: problem with # in path
Peter Mikeska [EMAIL PROTECTED] writes: Hi, im trying get all from wget -r -l 0 ftp://19.24.24.24/some/datase/C#Tool/ Replace the # with %23 and it should work.
Re: problem with # in path
Post, Mark K [EMAIL PROTECTED] writes: It's more likely your system/shell that is doing it, if you're using Linux or UNIX. The shell will typically only consider pound signs comments if they are preceded with whitespace (and appear outside quotes, etc.) In this case, the culprit is Wget's URL parser, which considers the part after the # to be the fragment identifier.
Re: wget-1.9.1: a minor patch for SGI IRIX 6.5
Thanks for the patch. A similar fix is already in CVS.
Re: mms:// URLs
On Fri, Jan 23, 2004 at 08:16:43PM -0500, Philip Mak wrote: Is there any future plan to include support for mms:// URLs in wget? Or any command-line Linux utility that can download mms:// URLs? (mms:// is streaming multimedia files; I'd like to be able to download the entire file.) I found a utility that can do it called Major MMS. http://www.geocities.com/majormms/ I think it would be nice if wget incorporated this functionality, since mms:// URLs are so widespread. Major MMS is GPL.
