Re: Session variables and POST method

From: Thomas Scheiderich (tfs_at_deltanet.com)
Date: 02/09/04 

Date: Mon, 09 Feb 2004 14:11:58 -0800

Peter Foti wrote:

> "Thomas Scheiderich" <tfs@deltanet.com> wrote in message
> news:4027CEB5.2010403@deltanet.com...
>
>>Peter Foti wrote:
>>
>>
>>>"Thomas Scheiderich" <tfs@deltanet.com> wrote in message
>>>news:402515A8.1080707@deltanet.com...
>>>
>>>
>>>>Peter Foti wrote:
>>>>
>>>>
>>>>
>>>>>"Thomas Scheiderich" <tfs@deltanet.com> wrote in message
>>>>>news:4023F533.5050400@deltanet.com...
>>>>>
>>>>>
>>>>>
>>>>>>I am trying to understand Session variables and ran into a question on
>>>>>>how they work with data that is passed.
>>>>>>
>>>>>>I have an HTM file that calls an ASP file and sends the name either by
>>>>>>GET or POST.
>>>>>>
>>>>>>When I find is that if I send the value by the GET method,
>>>>>>response.write("From QueryString: " &
>>>>>>Request.QueryString("usernamefromform") & "<br><br>")
>>>>>>
>>>>>>will get the variable fine, but
>>>>>>
>>>>>>Session("userName")=request.Form("userNameFromForm")
>>>>>>response.write("Session variable = " & Session("userName"))
>>>>>>
>>>>>>doesn't work.
>>>>>>
>>>>>>If I use the POST method then it is reversed. Response.QueryString
>>>>>>doesn't get anything and the Session code works.
>>>>>>
>>>>>>Why is this? I can't seem to find an explanation in my ASP books.
>>>>>>
>>>>>>
>>>>>>
>>>>>When using method GET, you can access the form values via the
>>>>>Request.Querystring collection. When using method POST, you can access
>>>>>
>>>>>
>>>the
>>>
>>>
>>>>>form values via the Request.Form collection.
>>>>>
>>>>>
>>>>>
>>>>Why is that?
>>>>
>>>>Aren't they both forms? I would have thought that the Request.Form,
>>>>would still be able to get the data.
>>>>
>>>>I know that the difference between GET and POST is that you can see the
>>>>data that is passed in the URL line in your browser, but you can't in
>>>>the POST method.
>>>>
>>>>
>>>The method actually specifies which HTTP method is used to send the form
>>>
> to
>
>>>the processing agent. With the HTTP "get" method, the form data is
>>>
> appended
>
>>>to the URI specified by the action attribute, and this new URI is sent
>>>
> to
>
>>>the processing agent. With the HTTP "post" method, the form data is
>>>included in the body of the form and sent to the processing agent.
>>>
> Thus,
>
>>>with the "get" method, your form data is transferred to the querystring,
>>>
> and
>
>>>with the "post" method, it remains in the form.
>>>
>>
>>This is a "just curious" question as I understand now what "post" does,
>>but everyone says that the "post" method is appended to the form data
>>and then passed to the processing agent.
>>
>>In the "get" method, the URL/URI with the query string appended after
>>the "?" is sent to the processor. What is actually sent to the
>>processor for "POST"? When you say the body of the form with the form
>>data, are you talking about an HTML page that just has the form
>>information (no graphics,tables etc.).
>>
>
> When a form is submitted for processing, some controls have their name
> paired with their current value and these pairs are submitted with the form.
> Those controls for which name/value pairs are submitted are called
> successful controls.
>
> Read this section of the spec for more details regarding how form data is
> processed:
> http://www.w3.org/TR/html4/interact/forms.html#h-17.13.3
>
> In addition, you might read the relavent portions of the HTTP spec (section
> 9.5 for example):
> http://www.ietf.org/rfc/rfc2616.txt
>

That was what I was looking for (this and Marks comments).

Thanks,

Tom.

>
>
>>I assume the data somehow gets sent to the client for the browser to
>>handle. Where does the data get put for the client to handle for things
>>such as putting into cookies as well as putting on the screen?
>>
>
> Why would you assume such a thing??? Form processing occurs on the server,
> not on the client or browser. The server can tell the client that there is
> a cookie, and that is handled by each browser individually (as far as where
> is stores the cookie).
>
> The spec should answer most of your questions.
> Regards,
> Peter Foti
>
>
>

Relevant Pages

  • Re: Bypass Authentication
    ... Set-Cookie get established on the Client upon a Successful logon. ... planning on capturing the cookie on Location 3. ... Upon Launching the browser ... "Joe Kaplan" wrote: ...
    (microsoft.public.dotnet.security)
  • Re: Bypass Authentication
    ... For the second question, it may be the case that there is a cookie, but it ... Joe Kaplan-MS MVP Directory Services Programming ... turn creates a cookie on the client and launch the browser, ... cookie already on the local client that the browser would then send. ...
    (microsoft.public.dotnet.security)
  • Re: How to configure IE using Javascript
    ... You cannot modify security settings via javascript. ... you can not modify cookie settings. ... security issues for client and browser should keep safe client side. ...
    (microsoft.public.scripting.jscript)
  • Re: alert box and problem with back button
    ... My problem was about client side as Ethem said.It is a way to close cache ... browser a expires immediate like header. ... alert a unique Id and storing it into a cookie, and in the jscript code, ... button of the browser, jscript code runs again in the client side, but it ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Attempt to de-mystify AJAX
    ... > conviction when we know the client is leading ... > code into the browser that it's now just as thick as anything people ... > 1) IT used to think BUI development was easy. ... > 2) Therefore IT people advocated thin client. ...
    (comp.databases.pick)