«

Scott Sauyet wrote:
> On Jan 26, 5:55 am, Erwin Moller
> <Since_humans_read_this_I_am_spammed_too_m...@spam yourself.com> wrote:
>> Eric Bednarz schreef:
>>> I would like an example of an HTTP request that simultaneously uses the
>>> HTTP GET and POST methods.
>> Here is one:
>>
>> <form action="whatever.php?id=12" Method="POST" name="testform">
>> Firstname: <input type="text" name="firstname">
>> <input type="submit">
>> </form>
>> [ ... ]
>> It is a bit weird I admit, but it works just fine.
>
> Well, this still is an HTTP POST request. PHP interprets the query
> string of the URL as GET variables, but it is not a GET request.
>
IUf that isn't what a GET is, I dunno WTF is...
> -- Scott

Scott Sauyet wrote:
> On Jan 26, 2:16 pm, "Evertjan." <exjxw.hannivo...@interxnl.net> wrote:
>> Scott Sauyet wrote on 26 jan 2010 in comp.lang.javascript:
>>> On Jan 26, 5:55ÿam, Erwin Moller
>>> Well, this still is an HTTP POST request. PHP interprets the query
>>> string of the URL as GET variables, but it is not a GET request.
>> So we should define a GET request in the OQ sense just as a any request
>> that is not a HTTP POST request [disregarding the HEAD request which has no
>> clientside coding ability]?
>
> No, but there is a specific verb given in the HTTP specification that
> is used for each request. If that request responds with a page, there
> is no client-side way from that page to know what verb was used; of
> course additional server-side help can easily be supplied. That's
> what I said in my original response.
>
>> You could do that, but what would be the use for the OP?
>
> I don't know what the OP needs, but if it's to know, for instance,
> that the current page is in response to a POST request, I believe that
> this is not possible in general without server-side help.
>
True. Which was the Elf's point.

> -- Scott

Eric Bednarz wrote:
> "Evertjan." <> writes:
>
>> Thomas 'PointedEars' Lahn wrote on 25 jan 2010 in comp.lang.javascript:
>
>>> Scott Sauyet wrote:
>
>>>> [OP, ed.]
>
>>>>>> Is there a way to know if the current page is a result of a get or
>>>>>> post?
>
>>>> var httpMethod = "<?php echo $_SERVER['REQUEST_METHOD']; ?>"
>>> See, there is a way
>> No there is not.
>
> I read that as wanting to know the request method, and I would think
> that a HTTP server cannot resolve a resource and send response headers
> without knowing that.
>
> I wonder what you read.

The Elf read it exactly as it was written.

Is there a way to know? yes. No specification was given as to the entity
that was to do the determination.

The Natural Philosopher <> writes:

> Eric Bednarz wrote:
>> "Evertjan." <> writes:
>>
>>> Scott Sauyet wrote on 25 jan 2010 in comp.lang.javascript:
>>>
>>>> "Evertjan." <exjxw.hannivo...@interxnl.net> wrote:
>>
>>>>> The new page can never know if the page request is
>>>>> 1 a result of a bona fide form-get
>>>>> or
>>>>> 2 just from a link contaning an URL with querystring.
>>>> I'm not sure that is a meaningful distinction. At the HTTP level,
>>>> both are GET requests, so even the server doesn't distinguish this.
>>> No, they could also be POST requests at ther same time.
>>
>> I would like an example of an HTTP request that simultaneously uses the
>> HTTP GET and POST methods.
>
> I do it somewhat regularly..

While that may not be the kind of example I was hoping for, it was the
one I was expecting, so thank you.

> VERY possible with javascript.

I won’t doubt that, but writing an HTTP user agent and an HTTP server
that extend HTTP 1.1 in javascript is too ambitious a project for
me.

Sherm Pendley wrote:
> The Natural Philosopher <> writes:
>
>> Scott Sauyet wrote:
>>> Well, this still is an HTTP POST request. PHP interprets the query
>>> string of the URL as GET variables, but it is not a GET request.
>> [If] that isn't what a GET is, I dunno WTF is...
>
> The request method is given as part of the HTTP headers in the request
> that the browser sends. If a request begins with "GET foo.html HTTP/1.0",
> it's a GET request. If it begins with "POST foo.php?bar=baz HTTP/1.0",
> it's a POST request. A GET request can be HTTP headers alone, while a
> POST has to have a message body too.
>
> It's the verb in the first part of the request that determines the method,
> not the presence or lack of a query string in the requested URL.
>

what about GET foo.php?bar=baz HTTP/1.0"

That works:

You can use a URL to point to a program that will correctly receive that
command line and set up a response depending on it

POST foo.php?bar=baz HTTP/1.0 will be using post get and post variables,
if any are included in the message body.


its certainly possible to set a form variable and invoke a URL with a
get variable on the back and pick up BOTH variables.



> More info:
> <http://www.jmarshall.com/easy/http/>
>
> A *lot* more info:
> <http://www.w3.org/Protocols/rfc2616/rfc2616.html>
>
> sherm--

Sherm Pendley wrote:
> The Natural Philosopher <> writes:
>
>> Sherm Pendley wrote:
>>> The request method is given as part of the HTTP headers in the request
>>> that the browser sends. If a request begins with "GET foo.html HTTP/1.0",
>>> it's a GET request. If it begins with "POST foo.php?bar=baz HTTP/1.0",
>>> it's a POST request. A GET request can be HTTP headers alone, while a
>>> POST has to have a message body too.
>>>
>>> It's the verb in the first part of the request that determines the method,
>>> not the presence or lack of a query string in the requested URL.
>> what about GET foo.php?bar=baz HTTP/1.0"
>
> What about it? The verb is GET, so it's a GET request, whether or not
> the URL has a query string.
>
>> POST foo.php?bar=baz HTTP/1.0 will be using post get and post
>> variables, if any are included in the message body.
>
> The verb before the URL is POST, so it's a POST request, whether or
> not the URL has a query string.
>
> The fact that PHP stuffs query string variables into a PHP variable
> called $_GET is misleading, since it does so regardless of what kind
> of HTTP request method was actually sent by the browser.

WEll no, that's where you are wrong. It stuffs Get into $_GET and post
into $_POST.

The CGI standard defines GET method as using the URL and POST method as
using the message body.

NOTHING to do with whether the browser issues a GET or a POST *command*,
except I am not sure what a server would do with a GET command with a
body attached..

If ypu send as POST COMMAND, the server accepts both url encoded and
body encoded data. AND SEPARATES THEM.


..



>
>> its certainly possible to set a form variable and invoke a URL with a
>> get variable on the back and pick up BOTH variables.
>
> It's possible to send a POST request that includes variables as part
> of the message body, and other variables in the query string. Doing so,
> however, does not turn it into something other than a POST request.
>

But it does turn it into somethimg that uses the GET method of CGI
interfacing.

Don't confuse the two.

> sherm--

Sherm Pendley wrote:
> The Natural Philosopher <> writes:
>
>> Sherm Pendley wrote:
>>> The Natural Philosopher <> writes:
>>>
>>> The fact that PHP stuffs query string variables into a PHP variable
>>> called $_GET is misleading, since it does so regardless of what kind
>>> of HTTP request method was actually sent by the browser.
>> WEll no, that's where you are wrong. It stuffs Get into $_GET and post
>> into $_POST.
>
> I hate to be the one to break it to you, but not everyone who disagrees
> with you is wrong.
>
>> The CGI standard defines GET method as using the URL and POST method
>> as using the message body.
>
> LOL! GET and POST are defined by HTTP.
>
> You're too clueless to argue with - you'll have to educate yourself
> without my help from here on out. Sorry.
>
>> But it does turn it into somethimg that uses the GET method of CGI
>> interfacing.
>>
>> Don't confuse the two.
>
> I'm not confused jackass. And f**k you for saying so.
>

GET and POST are also defined in the English dictionary.



You might care to GET a life and POST your angst somewhere else.


> *plonk*
>
> sherm--