"Suhas Tembe" <[EMAIL PROTECTED]> writes:
> It does look a little complicated This is how it looks:
>
>
> 454A
> 454B
>
Those are the important parts. It's not hard to submit this form.
With Wget 1.9, you can even use the POST method, e.g.:
wget http://.../InventoryStatus.asp --post-data
It does look a little complicated This is how it looks:
Supplier
454A
454B
Quantity Status
Over
Under
Both
All
I don't see any specific URL that would get the relevant data after I hit submit.
Maybe I am missing something...
Thanks,
Suhas
- Origin
"Suhas Tembe" <[EMAIL PROTECTED]> writes:
> this page contains a "drop-down" list of our customer's locations.
> At present, I choose one location from the "drop-down" list & click
> submit to get the data, which is displayed in a report format. I
> "right-click" & then choose "view source" & save
Got it! Thanks! So far so good. After logging-in, I was able to get to the page I am
interested in. There was one thing that I forgot to mention in my earlier posts (I
apologize)... this page contains a "drop-down" list of our customer's locations. At
present, I choose one location from the "dro
"Suhas Tembe" <[EMAIL PROTECTED]> writes:
> Thanks everyone for the replies so far..
>
> The problem I am having is that the customer is using ASP & Java
> script. The URL stays the same as I click through the links.
URL staying the same is usually a sign of the use of frame, not of ASP
and J
Josh Brooks <[EMAIL PROTECTED]> writes:
>> > At first it will act normally, just going over the site in question, but
>> > sometimes, you will come back to the terminal and see if grabbing all
>> > sorts of pages from totally different sites (!)
>>
>> The only way I've seen it happen is when it fo
Thanks everyone for the replies so far..
The problem I am having is that the customer is using ASP & Java script. The URL stays
the same as I click through the links. So, using "wget URL" for the page I want may
not work (I may be wrong). Any suggestions on how I can tackle this?
Thanks,
Su
Hrvoje Niksic wrote:
> That would work for short streaming, but would be pretty bad in the
> mkisofs example. One would expect Wget to be able to stream the data
> to the server, and that's just not possible if the size needs to be
> known in advance, which HTTP/1.0 requires.
One might expect it
Thank you for the great response. It is much appreciated - see below...
On Tue, 7 Oct 2003, Hrvoje Niksic wrote:
> www.zorg.org/vsound/ contains this markup:
>
>
>
> That explicitly tells robots, such as Wget, not to follow the links in
> the page. Wget respects this and does not follow t
Josh Brooks <[EMAIL PROTECTED]> writes:
> I have noticed very unpredictable behavior from wget 1.8.2 -
> specifically I have noticed two things:
>
> a) sometimes it does not follow all of the links it should
>
> b) sometimes wget will follow links to other sites and URLs - when the
> command line
"Tony Lewis" <[EMAIL PROTECTED]> writes:
> Hrvoje Niksic wrote:
>
>> I don't understand what you're proposing. Reading the whole file in
>> memory is too memory-intensive for large files (one could presumably
>> POST really huge files, CD images or whatever).
>
> I was proposing that you read the
Hrvoje Niksic wrote:
> I don't understand what you're proposing. Reading the whole file in
> memory is too memory-intensive for large files (one could presumably
> POST really huge files, CD images or whatever).
I was proposing that you read the file to determine the length, but that was
on the
Hello,
I have noticed very unpredictable behavior from wget 1.8.2 - specifically
I have noticed two things:
a) sometimes it does not follow all of the links it should
b) sometimes wget will follow links to other sites and URLs - when the
command line used should not allow it to do that.
Here
Martin, thanks for the patch and the detailed report. Note that it
might have made more sense to apply the patch to the latest CVS
version, which is somewhat different from 1.8.2.
I'm really not sure whether to add this patch. On the one hand, it's
nice to support as many architectures as possib
Hello Hrvoje and Dan,
I have been using wget for many years now, and finally got to applying
a patch I made long ago (EBCDIC patch against wget-1.5.3) to the
current wget-1.8.2. This patch makes wget compile and run on a
mainframe computer using the EBCDIC character set.
Also, when compiling wget
Am Dienstag, 07.10.03, um 17:02 Uhr (Europe/Berlin) schrieb Hrvoje
Niksic:
That's probably true. But have you tried sending without
Content-Length and Connection: close and closing the output side of
the socket before starting to read the reply from the server?
That might work, but it sounds too d
Stefan Eissing <[EMAIL PROTECTED]> writes:
> Am Dienstag, 07.10.03, um 16:36 Uhr (Europe/Berlin) schrieb Hrvoje
> Niksic:
>> What the current code does is: determine the file size, send
>> Content-Length, read the file in chunks (up to the promised size) and
>> send those chunks to the server. Bu
Karl Eichwalder <[EMAIL PROTECTED]> writes:
> I guess, you as the wget maintainer switched from something
> supported to the unsupported "betaX" scheme and now we have
> something to talk about ;)
I had no idea that something as usual as "betaX" was unsupported. In
fact, I believe that "bX" was
Am Dienstag, 07.10.03, um 16:36 Uhr (Europe/Berlin) schrieb Hrvoje
Niksic:
What the current code does is: determine the file size, send
Content-Length, read the file in chunks (up to the promised size) and
send those chunks to the server. But that works only with regular
files. It would be reall
"Tony Lewis" <[EMAIL PROTECTED]> writes:
> Hrvoje Niksic wrote:
>
>> Please be aware that Wget needs to know the size of the POST
>> data in advance. Therefore the argument to @code{--post-file}
>> must be a regular file; specifying a FIFO or something like
>> @file{/dev/stdin} wo
Hrvoje Niksic wrote:
> Please be aware that Wget needs to know the size of the POST data
> in advance. Therefore the argument to @code{--post-file} must be
> a regular file; specifying a FIFO or something like
> @file{/dev/stdin} won't work.
There's nothing that says you have to
Karl Eichwalder <[EMAIL PROTECTED]> writes:
> Hrvoje Niksic <[EMAIL PROTECTED]> writes:
>
>> Ouch. Why does the robot care about version names at all?
>
> It must know about the sequences; this is important for merging
> issues. IIRC, we have at least these sequences supported by the
> robot:
>
Karl Eichwalder <[EMAIL PROTECTED]> writes:
> Hrvoje Niksic <[EMAIL PROTECTED]> writes:
>
>> I'm not sure what "b3" is, but the version in the POT file was
>> supposed to be "beta3". Was there a misunderstanding somewhere along
>> the line?
>
> Yes, the robot does not like beta3 as part of the ve
Karl Eichwalder <[EMAIL PROTECTED]> writes:
>> Also, my Croatian translation of 1.9 doesn't seem to have made it
>> in. Is that expected?
>
> Unfortunately, yes. Will you please resubmit it with the subject line
> updated (IIRC, it's now):
>
> TP-Robot wget-1.9-b3.hr.po
I'm not sure what "b
Karl Eichwalder <[EMAIL PROTECTED]> writes:
> Hrvoje Niksic <[EMAIL PROTECTED]> writes:
>
>> As for the Polish translation, translations are normally handled
>> through the Translation Project. The TP robot is currently down, but
>> I assume it will be back up soon, and then we'll submit the POT
Dan Jacobson <[EMAIL PROTECTED]> writes:
> -q and -S are incompatible and should perhaps produce errors and be
> noted thus in the docs.
They seem to work as I'd expect -- `-q' tells Wget to print *nothing*,
and that's what happens. The output Wget would have generated does
contain HTTP headers,
Thanks!
Hrvoje Niksic <[EMAIL PROTECTED]> writes:
> As for the Polish translation, translations are normally handled
> through the Translation Project. The TP robot is currently down, but
> I assume it will be back up soon, and then we'll submit the POT file
> and update the translations /en masse/.
It
Zitat von Hrvoje Niksic <[EMAIL PROTECTED]>:
> Jochen Roderburg <[EMAIL PROTECTED]> writes:
>
> > Zitat von Hrvoje Niksic <[EMAIL PROTECTED]>:
> >
> >> It's a feature. `-A zip' means `-A zip', not `-A zip,html'. Wget
> >> downloads the HTML files only because it absolutely has to, in order
> >>
On Tue, 7 Oct 2003, Hrvoje Niksic wrote:
> My first impulse was to bemoan Wget's antiquated HTTP code which doesn't
> understand "chunked" transfer. But, coming to think of it, even if Wget
> used HTTP/1.1, I don't see how a client can send chunked requests and
> interoperate with HTTP/1.0 server
Theoretically, a HTTP/1.0 server should accept an unknown content-length
if the connection is closed after the request.
Unfortunately, the response 411 Length Required, is only defined in
HTTP/1.1.
//Stefan
Am Dienstag, 07.10.03, um 01:12 Uhr (Europe/Berlin) schrieb Hrvoje
Niksic:
As I was wri
31 matches
Mail list logo