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

[michaelr_41@xxxxxxxxxxxxxx]

Sender: michaelr_41@xxxxxxxxxxxxxx

I didn't bother using the hex codes for '<' and '>' since the other side
has a bigger issue anyway - since I can only pass 256 with a GET, and the
data (tags only, not even the 'real' data) is about 1800 bytes, there's
no way I can get it to him anyway. So I emailed him and said we need to
implement POST (correctly). 

Thanks...

- Michael

On Wed, 12 May 2004 14:07:32 -0500 (CDT), "Scott Klement"
<sk@xxxxxxxxxxxxxxxx> said:
> 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
> -----------------------------------------------------------------------
-- 
  
  michaelr_41@xxxxxxxxxxxxxx

-- 
http://www.fastmail.fm - Does exactly what it says on the tin
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------