just because it generally works doesn't mean its supposed to ;)
I've written quite a number of sites that have a modularised form input parser, that accepts
input both from GET requests and POSTs, and transparently converts it into a global hash. you'll
probably find that most sites do this for convenience, meaning that you can magically put POST
data up using a GET header. its not how its "supposed" to be done though ;)
find the http rfc (or a handy dandy human readable rundown of it ;) and have a squiz
at the difference between get and post.
post is more like a page download itself, with a full set of headers, content length,
content type, a blank line (technically a pair of newlines) and then data.
there are a few different encoding mechanisms as well. there's the normal one, or you
can specify the multipart/form-data one used in emails with the enctype= option in the
form tag. multipart/form-data is pretty much the standard for file uploads and
suchforth, as otherwise the browser can't supply a filename!
drop keywords into google for more info and specifics :)
oh, btw: if you do a POST header, afaik you MUST supply a valid content-type, or else
the server won't know when you're finished uploading! same reason that keep-alive
doesn't work for cgi scripts that don't supply content-length... hard to stick another
header on a socket when you don't know if its done doing the last page yet or not...
On Mon, 28 Jun 2004 16:26:08 -0700, bruce <[EMAIL PROTECTED]> wrote:
john...
thanks for the response...
however, if you examine the headers between the server/browser app, you can
more or less.. see what's being transfered back/forth... in this case, the
content/post data is available, and looks to be some ~6k of data...
it was my understanding that combining this information with the URl,
"""should""" be able to get to the targeted page.. assuming all things are
equal.. however.. this does not appear to be the case..
i've been able to successfully simulate what a post does with a number of
sites, by simply combining the URL with the requisite data and dropping the
result into a browser address ..withthe targeted page being successfully
displayed...
-----Original Message-----
From: John J Lee [mailto:[EMAIL PROTECTED]
Sent: Monday, June 28, 2004 3:35 PM
To: [EMAIL PROTECTED]
Subject: Re: url/query question...
This is nothing to do with win32, so I've cut that list from the To: line.
On Sun, 27 Jun 2004, bruce wrote:
[...]
i was under the impression that if i concatenated the url and the
content/query from the headers, that i'd be able to "simulate" the submit
What do you mean by "the content/query from the headers"? I guess you
mean the POST data? POST data != header data. An HTTP request contains
1. GET / POST line (containing the URL path), 2. headers, and 3. data.
If you're taking a POST request you sniffed by some means, and issuing the
corresponding GET request (GET /foo.cgi?post=data&goes=here HTTP/1.1),
then, yes, whether or not that works is indeed entirely dependent on the
way the code on the server was written.
[...]
with the stjohn's site, the header information indicates that ~6-8k of
information is in the content portion of the URL. could this be correct??
Yes.
when i try to stuff this much (cut/paste) into the browser url/address it
cuts it off..
Don't do that, then. Do a POST instead, using LWP.
i was under the impression that you were limited with regards
to the size of the content/query portion of the URL...
[...]
Apparently so. POST data is not part of the URL, though.
John
_______________________________________________
Perl-Win32-Users mailing list
[EMAIL PROTECTED]
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
