Re: PaceServiceError GET vs. POST

[Greg Stein <gstein@xxxxxxxxxx>]

On Wed, Jun 23, 2004 at 09:52:58AM +0200, Julian Reschke wrote:
> Greg Stein wrote:
> 
> >Definitely. Your firewall/proxy has no idea what the heck the POST means
> >and doesn't know whether to allow or deny the thing. And don't say "look
> >in the body" -- that's very expensive for a firewall/proxy to do. Most of
> >them don't even try. The idea is to look at the HTTP method to figure out
> >what operation is intended.
> >
> >The simple fact is that you can argue POST is appropriate for EVERYTHING.
> >"Hey! I'd like that page's contents. Why don't I send it a post and it
> >will send back the contents?" "Time to modify the page, let's just POST
> >the new content to it." "I wonder what metadata is on that page? Let's
> >send a neat little POST to get that back." Nevermind that the better way
> >to do these is with GET, PUT, and PROPFIND.
> >
> >POST is your generic catch-all with zero semantic meaning. I would say
> >that you need to _justify_ using it, rather than continue to use it as a
> >default position which needs to be argued away from.
> 
> I fully agree with you here, Greg. However, this is an argument if favor 
> of "ERR", not "GET", right?

Well.. Tim said, "let's turn it around. why NOT the POST method?" My
response was to that specifically. Further, my point is that POST is a
very poor method when you have a particular semantic already in mind.

For this concrete case, yes: I wholeheartedly believe that an ERR(OR)
method is the appropriate mechanism, rather than a POST to some URI.

Cheers,
-g