One consideration for using POST is that character set handling for URLs is not always well defined, whereas the character set handling for the post data is. For example, if I want to send stuff like Æ, Ø or Å (norwegianl characters) on a URL, some servers expect ISO 8859, whereas others expect UTF 8.
Eirik On Aug 19, 2:51 am, Pops <[EMAIL PROTECTED]> wrote: > On Aug 18, 7:19 pm, Stephan Beal <[EMAIL PROTECTED]> wrote: > > > On Aug 19, 12:55 am, Pops <[EMAIL PROTECTED]> wrote: > >> What was you sending? > > i wasn't sending anything - > > hmmmm, ok, but that should keep with GET if you are not passing > parameters.? No? > > > Apache can be configured to allow/disallow POST for certain > > extensions. On my provider they have POST to HTML disabled (presumably > > it is enabled for SHTML, and is definitely enabled for PHP). > > Right. Its a moot point now since you were not sending data. :-) I > thought you were referring to using JSON and I was referring to all > servers (once you get pass URL restrictions) supporting standard > enclosement types or content-types, but not necessarily new specific > content-type headers for passing JSON or XML. I agree not all servers > will expect this yet. > > > My assumption was that > > load() would respect the default settings set for ajax(), which i > > subsequently set to use GET, but load() appears to ignore those > > options. Using get() worked around the problem, in any case. > > Right. I am not keen with the automatic logic to use POST if any > parameters are passed. I can see the possible reasons, but it should > be more flexible without having to abandon .load and customizing an > ajax call/setting. > > Thanks > > -- > HLS
