I pressed SEND to fast before correcting some typos and adding some
needed clarification: <sorry>
Here is the general rule of thumb:
Use POST when the data:
1) Produces a command line over 1024 characters.
GET has its line limits. Do not assume all servers will accept
anything much longer than that. Each server will have its default
settings. Practically speaking it would silly to assume that very
long lines are acceptable and I would use the magic numbers 255 as a
guideline for our own stuff, but 1024 is safe I think.
Here is what RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1"
The HTTP protocol does not place any a priori limit on the length
of
a URI. Servers MUST be able to handle the URI of any resource they
serve, and SHOULD be able to handle URIs of unbounded length if
they
provide GET-based forms that could generate such URIs. A server
SHOULD return 414 (Request-URI Too Long) status if a URI is longer
than the server can handle (see section 10.4.15).
Note: Servers ought to be cautious about depending on URI
lengths
above 255 bytes, because some older client or proxy
implementations might not properly support these lengths.
2) Has complex elements and by that, I mean:
- <textarea>
- <input type='"file".../>
Thats because of #1 above. :-)
3) Security:
What to add alittle more "security" that keep the average person from
hacking, i.e.
the silly user has to do alittle more than just type a URL in the
address bar.
This is because data is passed on URL with the GET command:
http://somedomain?yourdata
With POST, it does not use the ? command line syntax. It is send as
part of the HTTP block with a blank line separating the two. For
AJAX, its not support security, but for normal users, it does.
Hope this helps
--
HLS
On Sep 3, 9:00 pm, Pops <[EMAIL PROTECTED]> wrote:
> Duncan,
>
> Here is the general rule of thumb:
>
> Use POST when the data:
>
> 1) Produces a command line over 1024 characters (GET has its line
> limits)
>
> 2) Complex and by I mean:
>
> - <textarea>
> - <input type='"file".../>
>
> 3) Security:
>
> What to add alittle more "security" that keep the average person from
> hacking, i.e.
> the silly user has to do alittle more than just type a URL in the
> address bar.
>
> This is because data is passed on URL with the GET command:
>
> On Sep 3, 6:45 pm, Duncan Heal <[EMAIL PROTECTED]> wrote:
>
> > Hey
>
> > I must admit - I get a little confused about when to use GET and
> > POST. I was reading this which confused me further:> Getting lazy with GET
> > -- GET is for retrieving data; POST is for
> > > setting it. Don't use GET when you know you shouldn't, even if you
> > > think it will do no harm. GET operations change state, and links
> > > that change state are confusing to users; most are accustomed to
> > > links as guides to navigation, not function.
>
> >http://www.builderau.com.au/program/ajax/soa/The-Seven-Deadly-Sins-of-
> > AJAX-application-development/0,339028327,339274985,00.htm
>
> > My question: is it right to say that in a database/AJAX setting we
> > 'should' use GET to SELECT data and POST to UPDATE or INSERT.
>
> > Also, I find the ideas about changing state interesting. I find
> > myself building more 'action-based' web sites where arguably
> > navigation and function are becoming one in the same (even to the
> > point where I'm seriously considering replacing traditional
> > navigation in favour of action prompts). I would have thought that a
> > user's understanding is that when you click a link or a button
> > something changes - the state. I would then have thought his
> > statement about changing state via links as sorta redundant. Or is he
> > just suggesting we make links that change state work more like how a
> > form is submitted (and surely defeating some of the benefits of this
> > whole AJAX thing). I would welcome some of your thoughts 'cos I'm
> > confused and I think that creating usable ajax-interfaces is vital to
> > it's long term success (and not just sizzle).
>
> > Have a good day!
> > Duncan
> > - - - - - - - - - - - - - - - - -
> > Sprocket Web Designwww.sprocket.co.nz
> > - - - - - - - - - - - - - - - - -
