Re: Post Data
Re: Post Data
- Subject: Re: Post Data
- From: Brian Johnson <email@hidden>
- Date: Thu, 3 Jan 2002 10:39:04 -0800 (PST)
Doug, I'm swamped for time right now, so I'm only going to answer the easy
parts of this. I think you know almost all of this already, so please
excuse my didactic tone (it's an occupational hazard). Hopefully someone
else can contribute greater clarity on some of your other questions.
On Wed, 2 Jan 2002, Doug McNutt wrote:
[snips]
>
My followup questions:
>
>
What is the "set x to" phrase for on Brian's script? Is it a way to send
>
the download to the bit bucket? It may not have been clear that I really
>
wanted data to be returned and saved.
The result of the "download" (see below) is a file specification. Since
you tell it where to put the data anyway, it's not clearly needed, but
that's what it is.
>
"downloading" a URL typically means use HTTP to get either a named file
>
or a default called index.html from the server. In this case URL Access
>
sends only a POST request. How does it know to do that? How did I manage
>
to tell it that this request was somehow different from the usual
>
download with some form information appended?
Hmmm.... Can I call that "almost right"? (9 out of 10 points?) Here's how
I understand it... When you "submit" a form in a browser, the browser
emits a "POST" request (usually--see below). When you click on an anchor
<a href=xxx> it does a "GET". Without using Javascript, you cannot do two
GETs, two POSTS, or a mixture of POSTs and GETs in a single click.
CGIs get executed because you specify a URL on either a GET or a POST
which identifies the CGI executable as the 'target' of the request <a
href=/cgi-bin/test.acgi>for example</a>. The CGI may not need arguments
(if it returns a graphic for the system time, for instance), but it can be
passed certain environmental information (about the server and the
request) as well as certain "user supplied" data. The user data falls into
three categories:
"path arguments" are added by including a $-sign in the link <a
href=/cgi-bin/test.acgi$pathargs>like this</a>;
"search arguments" are added by including a ?-mark, <a
href=/cgi-bin/test.acgi?search_args>like this</a>; and
"POST arguments" (which have a much larger maximum size) are handled
differently. POST args cannot be "tacked on" to a regular URL
string like the other two, they are only passed in a "POST" event.
You can use forms to do GETs (<form action=something.html method=get>) and
you can use anchors to do limited execution of CGIs (or your 'scopes
innards, I suspect). Whether you use a GET or a POST, the URL resolves to
a file (either a data file or an executable application) and the server is
able to send back a lump of data (aka file) for the browser to chew on.
So URL Access Scripting is just a tool for controlling http file
downloads, through either GET or POST requests. The "form data" phrase
simply indicates that the request for data is a POST request. The "with
progress" controls display of a standard progress bar, and "with
unpacking" controls whether the file is unStuffed (if it's a StuffIt
archive, and possibly @ other times...) The "without a and b" syntax means
without doing either thing.
>
The 'scope has the option of downloading the data in pairs of 16 bit
>
bytes rather than ASCII text. It's much faster. Does the "unpacking"
>
option know about things like that?
probably not, though you might be able to sock away the binary data and
and then post-process it in another application
>
"without progress and unpacking";
>
does that include unpacking or not? My English teacher would never allow
>
that kind of ambiguity.
see above
>
Isn't there any way of learning these things without leaning on helpful
>
list members like Brian?
Check the URL access dictionary (in Script Editor, File Open Dictionary,
select ...) and poke and prod a lot (but if you're using a sniffer, you've
already got that part figured out).
Brian Johnson, Dept of Architecture, University of Washington, Seattle