[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: POST to an asp - I GET it :)



Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>


On Wed, 12 May 2004 michaelr_41@xxxxxxxxxxxxxx wrote:
>
> That was it...GET vs. POST. I changed the call to http_url_get_raw() and
> things came together. I had a string of data that contained angle
> brackets and that made the .asp choke, but I removed them and just passed
> 'hello'...and got 'hello' back.

Like I tried to say before, you can eliminate that problem by passing the
hex codes for the "angle brackets" (which are really greater
than/less-than signs)

For example:  '<' is ASCII x'3C' and '>' is ASCII x'3E' so if your data is
usually '<xmltag>MyData</xmltag>' you'd pass it with
'appreq=%3Cxmltag%3EMyData%3C/xmltag%3E' -- and that would solve the 400
error you were getting.

I think that the only "special" characters that need to be escaped in this
manner are "<>&?+%=" (but that's off the top of my head, so I could be
wrong) oh yeah, plus any unprintable characters would need to be encoded
this way as well, such as CRLF.

In addition to that, spaces need to be translated into plus symbols.
(Though, you could use %20 instead if you like, since x'20' is ASCII
space)

So for example, if your data was supposed to be '<xmltag>My Cool
Data</xmltag>' you would change it into:
    'appreq=%3Cxmltag%3EMy+Cool+Data%3C/xmltag%3E'

As I mentioned before, I'm working on a routine that I'll add to HTTPAPI
that you can call to make this transformation, but it's not done yet.


> So, it's back to the developer on the other side to find out what they
> want to do - implement POST correctly or use GET and have limitations.
>
> Correct me if I'm wrong, but one of the limitations of GET is that it
> uses environment variables and there is a limit to the size of the data
> that can be passed, while POST uses name=value pairs and can be rpetty
> much unlimited. Is that correct?

In both GET and POST situations they use "name=value" pairs IF the data is
being submitted via a web form (which is the case in your application)

In most web server implementations, yes, GET receives it's value with an
environment variable, whereas POST reads the data from the standard input
(which is similar to reading a file)  So there's a limitation there, as
environment variables have a max size.  (The max size differs depending on
the platform, though.  It may be larger on Windows than it would be
on an iSeries, or vice-versa... I don't know the details.)

But, assuming that you're planning to use HTTPAPI, you've got a much
bigger limitation than that -- HTTPAPI uses 256-byte URLs.  (I do want to
expand this, you're not the first one to have problems with this limit!)

So, if you've got "http://www.xxxx.com/xxxxxx/sample3.asp"; that's already
38 bytes, leaving you with a total of 218 bytes for your encoded URL on a
GET request.

When I increase this in the next release, I'll probably use a VARYING
string that can be up to 32k long, which should eliminate that problem.

A POST request, by contrast, sends data as a stream -- similar to a
stream file or user space -- and therefore there's really no limit to how
large the data can be.

Also, with a POST request, the data does not necessarily need to be
URL-encoded (the %xx stuff I mentioned) because it's not being sent as
part of the URL.   (Though, some applications may still require it to be
encoded because of the way that they were written.)

At any rate, your vendor needs to think long and hard about sending out an
HTML page that sends a request using a POST method, but not actually
sending the parameters as "POST data".  That's REALLY counter-intuitive.
If you MUST encode the parameters in the URL, use GET!
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------