On Aug 18, 6:15 pm, Stephan Beal <[EMAIL PROTECTED]> wrote:
> One of the negative side-effects is, however, that POST is not
> configured consistently across servers. For example, i had the example
> same problem as the OP... i was trying to load() an HTML file and it
> worked on my local system. When, however, i uploaded it to my hoster
> the code suddenly failed. Firebug revealed that POST was erroring out
> on my hoster because POST was not allowed for HTML files on that
> server. So i had to rework the code to use get(). i remember trying to
> set GET as the default ajax behaviour and that load() ignored that.
What was you sending?
We write our own web server and as such we conform to HTTP RFC
standards, and it was never a consideration to be aware of
"configuration" options for standard GET/POST required operations. I
mean, a web server either supports proper RFC 1945 (HTTP 1.0) or RFC
2616 (HTTP 1.1) or it doesn't in which case, its broken :-)
That said, I can guess at what you might have seen with different
server behavior:
1) Poor, unflexible and/or different support for MIME parsing and
exposing the info to server-side scripts. For example, file uploads.
There is only 1 way to POST it via a browser using MIME. However, how
that file upload is exposed by the receiving WEB Server to server side
applications is not consistent. Not a standard consideration across
servers. We do it one way, Apache, IIS may do it another way. So
possibly, since JSON and XML is relatively new, it is also a non-
standard in how a server will expose this information to server-side
applets. Definitely a bridge I will be crossing very soon. :-)
2) Or you came across an old server bug that most worthy web servers
have fixed at this point in time. It was related to not flushing the
final <CR><LF> bytes that appears in posted data. The RFC does were
ambigious here. But the bug was presence in servers for many years
and only show its ugly head when more users came on board with high
bandwidh DSL speeds that differ in direction. Fast input (downloads),
slow output (uploads) created a "timing issue" which causes a TCP/IP
frame reset. The visual error for users was "PAGE NOT FOUND."
--
HLS
