Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #15534 > unrolled thread

XMLHttpRequest: POST with Data

Back to article view | Back to comp.lang.javascript

Contents

  XMLHttpRequest: POST with Data Gene Wirchenko <genew@ocis.net> - 2012-08-23 15:00 -0700
    Re: XMLHttpRequest: POST with Data "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-08-23 22:48 +0000
      Re: XMLHttpRequest: POST with Data Gene Wirchenko <genew@ocis.net> - 2012-08-23 16:40 -0700
        Re: XMLHttpRequest: POST with Data "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-08-26 20:39 +0000
    Re: XMLHttpRequest: POST with Data Christoph Becker <cmbecker69@gmx.de> - 2012-08-24 01:11 +0200
      Re: XMLHttpRequest: POST with Data Gene Wirchenko <genew@ocis.net> - 2012-08-23 16:42 -0700
        Re: XMLHttpRequest: POST with Data Christoph Becker <cmbecker69@gmx.de> - 2012-08-24 02:54 +0200
          Re: XMLHttpRequest: POST with Data Gene Wirchenko <genew@ocis.net> - 2012-08-23 19:04 -0700
            Re: XMLHttpRequest: POST with Data Tim Streater <timstreater@greenbee.net> - 2012-08-24 08:57 +0100
      Re: XMLHttpRequest: POST with Data Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-08-25 12:02 +0200
        Re: XMLHttpRequest: POST with Data Christoph Becker <cmbecker69@gmx.de> - 2012-08-25 14:09 +0200
          Re: XMLHttpRequest: POST with Data Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-08-25 15:20 +0200
            Re: XMLHttpRequest: POST with Data Christoph Becker <cmbecker69@gmx.de> - 2012-08-26 15:49 +0200
              Re: XMLHttpRequest: POST with Data Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-08-26 19:15 +0200
                Re: XMLHttpRequest: POST with Data Stefan Weiss <krewecherl@gmail.com> - 2012-08-26 19:54 +0200
                  Re: XMLHttpRequest: POST with Data Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-08-26 21:43 +0200
                Re: XMLHttpRequest: POST with Data Christoph Becker <cmbecker69@gmx.de> - 2012-08-26 23:42 +0200
    Re: XMLHttpRequest: POST with Data Denis McMahon <denismfmcmahon@gmail.com> - 2012-08-24 02:55 +0000
    Re: XMLHttpRequest: POST with Data "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2012-08-23 19:28 -0700
    Re: XMLHttpRequest: POST with Data "Tom de Neef" <tdeneef@qolor.nl> - 2012-08-24 15:58 +0200
    Re: XMLHttpRequest: POST with Data Ross McKay <au.org.zeta.at.rosko@invalid.invalid> - 2012-08-26 08:38 +1000
    Re: XMLHttpRequest: POST with Data Mike Winter <usenet@michael-winter.me.invalid> - 2012-08-26 14:59 +0100

Page 1 of 2  [1] 2  Next page →

#15534 — XMLHttpRequest: POST with Data

Dear JavaScripters:

     I am trying to pass data back and forth using XMLHttpRequest.  I
have run into a few issues.  The first one is the most important.

  1) I can not get POST to work according to various documentation I
have found on the Web.

     Suppposedly, the .open() and .send() would be
          oRequest.open("POST",Url,true);
          oRequest.send(DataToSend);
but with this, at the server end, the .QueryString value is ""
regardless of what was supposedly sent.

     I have found that using the GET style of
          oRequest.open("POST",Url+"?"+DataToSend,true);
          oRequest.send();
does work.  At least, it appears to.

     Am I doing something wrong, or is the documentation wrong?

  2) What should I do for escaping of data?  Going to the server, any
line breaks get eaten somewhere so I use escape() at browser and
unescape() at server.  Going from server to browser, line break are
not eaten.  Does this mean that I do not have to escape()/unescape()
on the trip back?

     Are escape() and unescape() the correct functions to use?

Sincerely,

Gene Wirchenko

[toc] | [next] | [standalone]

#15537

Gene Wirchenko wrote on 24 aug 2012 in comp.lang.javascript:

>           oRequest.open("POST",Url+"?"+DataToSend,true);
>           oRequest.send();
> 

oRequest.open("POST",Url,true);
oRequest.send(DataToSend);


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#15541

On 23 Aug 2012 22:48:35 GMT, "Evertjan."
<exxjxw.hannivoort@inter.nl.net> wrote:

>Gene Wirchenko wrote on 24 aug 2012 in comp.lang.javascript:
>
>>           oRequest.open("POST",Url+"?"+DataToSend,true);
>>           oRequest.send();

>oRequest.open("POST",Url,true);
>oRequest.send(DataToSend);

     As I posted, that does not work.  .QueryString is empty.  If I
should be looking at a different property server-side, which one?

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15578

Gene Wirchenko wrote on 24 aug 2012 in comp.lang.javascript:

> On 23 Aug 2012 22:48:35 GMT, "Evertjan."
> <exxjxw.hannivoort@inter.nl.net> wrote:
> 
>>Gene Wirchenko wrote on 24 aug 2012 in comp.lang.javascript:
>>
>>>           oRequest.open("POST",Url+"?"+DataToSend,true);
>>>           oRequest.send();
> 
>>oRequest.open("POST",Url,true);
>>oRequest.send(DataToSend);
> 
>      As I posted, that does not work.  .QueryString is empty.  If I
> should be looking at a different property server-side, which one?

request.querystring should be empty, because that reflects the data 
entered with a "GET"

request.form is where you should expect "POSP" data.


Example:


======== test-post.asp ================

<% ' vbscript
response.write "You posted: " & request.form("myPosted") & "<hr>"
%>

<form method='post'>
<input name='myPosted'> 
<input type='submit'>
</form>
======================================

======== test-querystring.asp ================

<% ' vbscript
response.write "You sent as querystring: " &_
  request.querystring("mysentwithGet") & "<hr>"
%>

<form>
<input name='mysentwithGet'> 
<input type='submit'>
</form>
======================================




-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#15540

Gene Wirchenko wrote:
> Dear JavaScripters:
> 
>      I am trying to pass data back and forth using XMLHttpRequest.  I
> have run into a few issues.  The first one is the most important.
> 
>   1) I can not get POST to work according to various documentation I
> have found on the Web.
> 
>      Suppposedly, the .open() and .send() would be
>           oRequest.open("POST",Url,true);
>           oRequest.send(DataToSend);
> but with this, at the server end, the .QueryString value is ""
> regardless of what was supposedly sent.

If you send a POST request (without any additional query string), no
query string will be sent (so .QueryString, which is supposedly .NET,
will be empty). You have to look at some other
property/variable/function (in PHP it would be $_POST).

> 
>      I have found that using the GET style of
>           oRequest.open("POST",Url+"?"+DataToSend,true);
>           oRequest.send();
> does work.  At least, it appears to.
> 
>      Am I doing something wrong, or is the documentation wrong?
> 
>   2) What should I do for escaping of data?  Going to the server, any
> line breaks get eaten somewhere so I use escape() at browser and
> unescape() at server.  Going from server to browser, line break are
> not eaten.  Does this mean that I do not have to escape()/unescape()
> on the trip back?
> 
>      Are escape() and unescape() the correct functions to use?

For POST requests escaping on the client side should not be necessary.
For GET requests encodeURI() resp. encodeURIComponent seem to be more
appropriate.

How to escape when sending data to the client depends.

> 
> Sincerely,
> 
> Gene Wirchenko

Hope that help a bit.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#15542

On Fri, 24 Aug 2012 01:11:40 +0200, Christoph Becker
<cmbecker69@gmx.de> wrote:

>Gene Wirchenko wrote:
>> Dear JavaScripters:
>> 
>>      I am trying to pass data back and forth using XMLHttpRequest.  I
>> have run into a few issues.  The first one is the most important.
>> 
>>   1) I can not get POST to work according to various documentation I
>> have found on the Web.
>> 
>>      Suppposedly, the .open() and .send() would be
>>           oRequest.open("POST",Url,true);
>>           oRequest.send(DataToSend);
>> but with this, at the server end, the .QueryString value is ""
>> regardless of what was supposedly sent.
>
>If you send a POST request (without any additional query string), no
>query string will be sent (so .QueryString, which is supposedly .NET,
>will be empty). You have to look at some other
>property/variable/function (in PHP it would be $_POST).

     .QueryString is in Classic ASP (which is what I am using).

>>      I have found that using the GET style of
>>           oRequest.open("POST",Url+"?"+DataToSend,true);
>>           oRequest.send();
>> does work.  At least, it appears to.
>> 
>>      Am I doing something wrong, or is the documentation wrong?
>> 
>>   2) What should I do for escaping of data?  Going to the server, any
>> line breaks get eaten somewhere so I use escape() at browser and
>> unescape() at server.  Going from server to browser, line break are
>> not eaten.  Does this mean that I do not have to escape()/unescape()
>> on the trip back?
>> 
>>      Are escape() and unescape() the correct functions to use?
>
>For POST requests escaping on the client side should not be necessary.
>For GET requests encodeURI() resp. encodeURIComponent seem to be more
>appropriate.
>
>How to escape when sending data to the client depends.

     But what does it depend on?  I get tired of guessing.  I would
like to get it right.

[snip]

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15543

Gene Wirchenko wrote:
> On Fri, 24 Aug 2012 01:11:40 +0200, Christoph Becker
> <cmbecker69@gmx.de> wrote:
> 
>> Gene Wirchenko wrote:
>>> Dear JavaScripters:
>>>
>>>      I am trying to pass data back and forth using XMLHttpRequest.  I
>>> have run into a few issues.  The first one is the most important.
>>>
>>>   1) I can not get POST to work according to various documentation I
>>> have found on the Web.
>>>
>>>      Suppposedly, the .open() and .send() would be
>>>           oRequest.open("POST",Url,true);
>>>           oRequest.send(DataToSend);
>>> but with this, at the server end, the .QueryString value is ""
>>> regardless of what was supposedly sent.
>>
>> If you send a POST request (without any additional query string), no
>> query string will be sent (so .QueryString, which is supposedly .NET,
>> will be empty). You have to look at some other
>> property/variable/function (in PHP it would be $_POST).
> 
>      .QueryString is in Classic ASP (which is what I am using).

I have no experience with ASP, but you might try Request.Form.

> 
>>>      I have found that using the GET style of
>>>           oRequest.open("POST",Url+"?"+DataToSend,true);
>>>           oRequest.send();
>>> does work.  At least, it appears to.
>>>
>>>      Am I doing something wrong, or is the documentation wrong?
>>>
>>>   2) What should I do for escaping of data?  Going to the server, any
>>> line breaks get eaten somewhere so I use escape() at browser and
>>> unescape() at server.  Going from server to browser, line break are
>>> not eaten.  Does this mean that I do not have to escape()/unescape()
>>> on the trip back?
>>>
>>>      Are escape() and unescape() the correct functions to use?
>>
>> For POST requests escaping on the client side should not be necessary.
>> For GET requests encodeURI() resp. encodeURIComponent seem to be more
>> appropriate.
>>
>> How to escape when sending data to the client depends.
> 
>      But what does it depend on?  I get tired of guessing.  I would
> like to get it right.

It depends heavily on the Content-Type you're sending (JSON, XML, HTML
etc.) and the "technique" you're using to constructing the response. But
anyway, this question might better be asked in an appropriate ASP
newsgroup or forum.

> 
> [snip]
> 
> Sincerely,
> 
> Gene Wirchenko
> 

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#15544

On Fri, 24 Aug 2012 02:54:42 +0200, Christoph Becker
<cmbecker69@gmx.de> wrote:

>Gene Wirchenko wrote:
>> On Fri, 24 Aug 2012 01:11:40 +0200, Christoph Becker
>> <cmbecker69@gmx.de> wrote:

[snip]

>>> How to escape when sending data to the client depends.
>> 
>>      But what does it depend on?  I get tired of guessing.  I would
>> like to get it right.
>
>It depends heavily on the Content-Type you're sending (JSON, XML, HTML
>etc.) and the "technique" you're using to constructing the response. But
>anyway, this question might better be asked in an appropriate ASP
>newsgroup or forum.

     Actually, undecided.  I expect that I will have to work out my
own data format.  That does not bother me.  What I need to know is
where to get the data from.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

#15548

In article <k6od38tlbh8qjlpuap4eluh7c486ohe944@4ax.com>,
 Gene Wirchenko <genew@ocis.net> wrote:

> On Fri, 24 Aug 2012 02:54:42 +0200, Christoph Becker
> <cmbecker69@gmx.de> wrote:
> 
> >Gene Wirchenko wrote:
> >> On Fri, 24 Aug 2012 01:11:40 +0200, Christoph Becker
> >> <cmbecker69@gmx.de> wrote:
> 
> [snip]
> 
> >>> How to escape when sending data to the client depends.
> >> 
> >>      But what does it depend on?  I get tired of guessing.  I would
> >> like to get it right.
> >
> >It depends heavily on the Content-Type you're sending (JSON, XML, HTML
> >etc.) and the "technique" you're using to constructing the response. But
> >anyway, this question might better be asked in an appropriate ASP
> >newsgroup or forum.
> 
>      Actually, undecided.  I expect that I will have to work out my
> own data format.  That does not bother me.  What I need to know is
> where to get the data from.

Or you can look at the working example here:

<http://www.clothears.org.uk/examples-ajax.php>

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#15553

Christoph Becker wrote:

> Gene Wirchenko wrote:
>>      I have found that using the GET style of
>>           oRequest.open("POST",Url+"?"+DataToSend,true);
>>           oRequest.send();
>> does work.  At least, it appears to.
>> 
>> […]
>>   2) What should I do for escaping of data?  Going to the server, any
>> line breaks get eaten somewhere so I use escape() at browser and
>> unescape() at server.  Going from server to browser, line break are
>> not eaten.  Does this mean that I do not have to escape()/unescape()
>> on the trip back?
>> 
>>      Are escape() and unescape() the correct functions to use?
> 
> For POST requests escaping on the client side should not be necessary.

Incorrect.  The payload of the POST request (the message body) needs to be 
URI-percent-encoded, see RFC 2616.

> For GET requests encodeURI() resp. encodeURIComponent seem to be more
> appropriate.

encodeURIComponent() is the function to be used for percent-encoding of each 
parameter name and value regardless of the request method.  The proprietary 
escape() and unescape() functions should not be used as they are not 
Unicode-safe.


PointedEars
-- 
> If you get a bunch of authors […] that state the same "best practices"
> in any programming language, then you can bet who is wrong or right...
Not with javascript. Nonsense propagates like wildfire in this field.
  -- Richard Cornford, comp.lang.javascript, 2011-11-14

[toc] | [prev] | [next] | [standalone]

#15554

Thomas 'PointedEars' Lahn wrote:
> Christoph Becker wrote:
>> For POST requests escaping on the client side should not be necessary.
> 
> Incorrect.  The payload of the POST request (the message body) needs to be 
> URI-percent-encoded, see RFC 2616.

Thanks for correcting me. I was not aware of this, as in the past I
always used jQuery to send Ajax POST requests, and the respective jQuery
methods obscure this fact by doing the encoding behind the scenes,
what's AFAIK not documented.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#15556

Christoph Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph Becker wrote:
>>> For POST requests escaping on the client side should not be necessary.
>> Incorrect.  The payload of the POST request (the message body) needs to
>> be URI-percent-encoded, see RFC 2616.
> 
> Thanks for correcting me. I was not aware of this, as in the past I
> always used jQuery to send Ajax POST requests, and the respective jQuery
> methods obscure this fact by doing the encoding behind the scenes,
> what's AFAIK not documented.

To be precise (I have had time to re-read the RFC), URI-percent-encoding is 
not mandatory.  But if the payload contains ASCII characters, a form of 
encoding that results in ASCII octets is.

Per section 4.3, RFC 2616 (HTTP/1.1) mandates that the message body must 
contain only ASCII octets.  This is easily accomplished in a symmetrical way 
with percent-encoding as defined in RFC 3986 ("Uniform Resource 
Identifiers"), section 2.1.  (In ECMAScript implementations this is 
implemented as the encodeURIComponent() function.)

The message body may also, instead, be encoded using the specified Transfer-
Encoding, the default of which is `identity' (no special encoding; see 
section 14.41).  Other Transfer-Encodings specified there already include 
the common `gzip', but AIUI as long as both client and server support it, 
any transfer encoding that results in an ASCII-only message body may be 
used.

It is possible that a browser API would apply a suitable encoding before 
transmitting the HTTP request message if it encountered non-ASCII characters 
in the payload.  However, that is nothing that should be relied upon.

The possibility of sending the payload gzipped instead of percent-encoded if 
the server supports it certainly should be investigated further.  This would 
make sense if the amount of client-side script code required for gzipping 
were less than the amount of data saved in the payload when switching from 
percent-encoding to gzipping.  On the other hand, it might be a good idea if 
browser APIs would use gzip transparently if supported by the server and 
deemed reasonable; previous gzipping by scripts would be of double 
disadvantage then.


Ceterum censeo jQuery esse delendam.

PointedEars
-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#15571

Thomas 'PointedEars' Lahn wrote:
> Per section 4.3, RFC 2616 (HTTP/1.1) mandates that the message body must 
> contain only ASCII octets.

I was not able to find the restriction on ASCII. RFC2616, section 7.2
mandates, that the entity-body has to contain OCTETs, where OCTET is
defined in section 2.2 as "any 8-bit sequence of data".

So for POST requests, when the Content-Type is text/plain (e.g. by using
<form enctype="text/plain">) even non-ASCII characters in the body can
be sent directly. But not all server side "languages" will handle this
(e.g. PHP will not fill in the $_POST variable). So it seems this is the
reason, why one should use Content-Type
application/x-www-form-urlencoded, which requires percent-encoding of
the request body.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#15574

Christoph Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Per section 4.3, RFC 2616 (HTTP/1.1) mandates that the message body must
>> contain only ASCII octets.
> 
> I was not able to find the restriction on ASCII. RFC2616, section 7.2
> mandates, that the entity-body has to contain OCTETs, where OCTET is
> defined in section 2.2 as "any 8-bit sequence of data".

I stand corrected.  However, section 19.3 alludes [1] to what is known as 
the "be conservative in what you do, liberal in what to accept from others" 
paradigm of the Internet ("Postel's law") [2].  Not knowing over which lines 
the HTTP message will be transmitted, and what the capabilities of the 
involved software are, it appears to be prudent to choose (the characters 
in) US-ASCII as the lowest common denominator.

When discussing character encoding, it should also be mentioned that not 
even choosing a specific Unicode encoding such as UTF-8 ensures 
compatibility.  The Macintosh operating system is known to use the more 
versatile, but in terms of memory footprint more expensive, character 
composition feature of Unicode, while other systems tend not to; as a 
result, the same character may be encoded using the same Unicode encoding in 
a different way and may need to be normalized in order to be compatible) 
[3].  This applies in particular to a Content Management System where some 
authors might use a Macintosh computer, while other authors and most 
visitors would not.  It should be investigated whether this applies to the 
implementations of the encodeURI() and encodeURIComponent() methods as well; 
ECMAScript, 5.1 Edition [4], do not mandate normalization before percent-
encoding.  (I have developed a novel approach [5] that is applicable to the 
ECMAScript Support Matrix [6] and similar kinds of research, and is going to 
help there.)

> So for POST requests, when the Content-Type is text/plain (e.g. by using
> <form enctype="text/plain">) even non-ASCII characters in the body can be
> sent directly. But not all server side "languages" will handle this (e.g.
> PHP will not fill in the $_POST variable).

PHP is not supposed to fill the $_POST array then; there are no parameters.  
Indeed, apparently there is no trivial way, if any, to retrieve the message 
body with PHP then; at least the input does not show up anywhere in 
phpinfo().

> So it seems this is the reason, why one should use Content-Type
> application/x-www-form-urlencoded, which requires percent-
> encoding of the request body.

I do not think so.  Instead, in addition to the reason I mentioned above, 
enctype="text/plain" is not mentioned in HTML 4.01 (but not forbidden by it 
either) [7], so it is unsurprising that some server-side applications with a 
longer development history would not support it.

Incidentally, the current HTML5 Working Draft places more constraints there, 
specifying "text/plain" as one of only three media types that are to be 
supported there. [8]  So apparently there are some, probably newer, server-
side applications that support it.


PointedEars
___________
[1] Fielding, R. et al. (1999-06). RFC 2616: Hypertext Transfer Protocol --
    HTTP/1.1.  §19.3: Tolerant Applications.
    <http://tools.ietf.org/html/rfc2616#section-19.3>
[2] Postel, Jon (ed.) (1980-01). RFC 761: Transmission Control Protocol.
    <http://tools.ietf.org/html/rfc761>
[3] Wikipedia contributors (2012-06-12). Wikipedia: Combining character.
    Retrieved 2012-08-26. <http://en.wikipedia.org/wiki/Combining_character>
[4] Ecma International (2011-06). Standard ECMA-262. 5.1 Edition.
    ECMAScript Language Specification (HTML rendering).
    §15.1.3: URI Handling Function Properties.
    <http://ecma-international.org/ecma-262/5.1/#sec-15.1.3>
[5] Lahn, Thomas (2012-03-12). Features von ECMAScript-basierten
    Programmiersprachen – Eine vergleichende Analyse (“Features of
    ECMAScript-based programming languages – A comparative analysis”).
    BSc SUPSI in Computer Science. Fernfachhochschule Schweiz
    (Swiss Distance-Learning University of Applied Sciences).
[6] Lahn, Thomas (2012-07-31). ECMAScript Support Matrix –
    There Is No Javascript. <http://PointedEars.de/es-matrix>
[7] Raggett, Dave, et al. (ed.). HTML 4.01 Specification.
    W3C Recommendation 24 December 1999. §17.3: The FORM element. 
    <http://www.w3.org/TR/1999/
     REC-html401-19991224/interact/forms.html#edef-FORM>
[8] Hickson, Ian (ed.). HTML5 – A vocabulary and associated APIs for
    HTML and XHTML. W3C Working Draft, 29 March 2012.
    §4.10.3 The form element. <http://www.w3.org/TR/html5/
    attributes-common-to-form-controls.html#attr-fs-enctype>
-- 
    realism:    HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness:    XHTML 1.1 as application/xhtml+xml
                                                    -- Bjoern Hoehrmann

[toc] | [prev] | [next] | [standalone]

#15575

On 2012-08-26 19:15, Thomas 'PointedEars' Lahn wrote:
> Christoph Becker wrote:
>> So for POST requests, when the Content-Type is text/plain (e.g. by using
>> <form enctype="text/plain">) even non-ASCII characters in the body can be
>> sent directly. But not all server side "languages" will handle this (e.g.
>> PHP will not fill in the $_POST variable).
> 
> PHP is not supposed to fill the $_POST array then; there are no parameters.  
> Indeed, apparently there is no trivial way, if any, to retrieve the message 
> body with PHP then [...]

file_get_contents("php://input")

or any other function capable of reading from streams.

- stefan

[toc] | [prev] | [next] | [standalone]

#15577

Stefan Weiss wrote:

> On 2012-08-26 19:15, Thomas 'PointedEars' Lahn wrote:
>> Christoph Becker wrote:
>>> So for POST requests, when the Content-Type is text/plain (e.g. by using
>>> <form enctype="text/plain">) even non-ASCII characters in the body can
>>> be sent directly. But not all server side "languages" will handle this
>>> (e.g. PHP will not fill in the $_POST variable).
>> PHP is not supposed to fill the $_POST array then; there are no
>> parameters. Indeed, apparently there is no trivial way, if any, to
>> retrieve the message body with PHP then [...]
> 
> file_get_contents("php://input")

Thanks, unfortunately it requires allow_url_fopen=1.

> or any other function capable of reading from streams.

Could you provide an example, please?


F'up2 comp.lang.php

PointedEars
-- 
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
  -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)

[toc] | [prev] | [next] | [standalone]

#15582

Thomas 'PointedEars' Lahn wrote:
> Christoph Becker wrote:
> 
>> Thomas 'PointedEars' Lahn wrote:
>>> Per section 4.3, RFC 2616 (HTTP/1.1) mandates that the message body must
>>> contain only ASCII octets.
>>
>> I was not able to find the restriction on ASCII. RFC2616, section 7.2
>> mandates, that the entity-body has to contain OCTETs, where OCTET is
>> defined in section 2.2 as "any 8-bit sequence of data".
> 
> I stand corrected.  However, section 19.3 alludes [1] to what is known as 
> the "be conservative in what you do, liberal in what to accept from others" 
> paradigm of the Internet ("Postel's law") [2].  Not knowing over which lines 
> the HTTP message will be transmitted, and what the capabilities of the 
> involved software are, it appears to be prudent to choose (the characters 
> in) US-ASCII as the lowest common denominator.

ACK

> When discussing character encoding, it should also be mentioned that not 
> even choosing a specific Unicode encoding such as UTF-8 ensures 
> compatibility.  The Macintosh operating system is known to use the more 
> versatile, but in terms of memory footprint more expensive, character 
> composition feature of Unicode, while other systems tend not to; as a 
> result, the same character may be encoded using the same Unicode encoding in 
> a different way and may need to be normalized in order to be compatible) 
> [3].  This applies in particular to a Content Management System where some 
> authors might use a Macintosh computer, while other authors and most 
> visitors would not.

Thanks for this information -- that comes in handy.

> It should be investigated whether this applies to the 
> implementations of the encodeURI() and encodeURIComponent() methods as well; 
> ECMAScript, 5.1 Edition [4], do not mandate normalization before percent-
> encoding. (I have developed a novel approach [5] that is applicable to the
> ECMAScript Support Matrix [6] and similar kinds of research, and is going to 
> help there.)

I took only a quick look at the "ECMAScript Support Matrix", but I
consider it a remarkable and valuable work.  I'll have a closer look at
it, and if my time and my abilities permit, I'll try to contribute.

>> So for POST requests, when the Content-Type is text/plain (e.g. by using
>> <form enctype="text/plain">) even non-ASCII characters in the body can be
>> sent directly. But not all server side "languages" will handle this (e.g.
>> PHP will not fill in the $_POST variable).
> 
> PHP is not supposed to fill the $_POST array then; there are no parameters.  
> Indeed, apparently there is no trivial way, if any, to retrieve the message 
> body with PHP then; at least the input does not show up anywhere in 
> phpinfo().
> 
>> So it seems this is the reason, why one should use Content-Type
>> application/x-www-form-urlencoded, which requires percent-
>> encoding of the request body.
> 
> I do not think so.  Instead, in addition to the reason I mentioned above, 
> enctype="text/plain" is not mentioned in HTML 4.01 (but not forbidden by it 
> either) [7], so it is unsurprising that some server-side applications with a 
> longer development history would not support it.

As Stefan mentioned in another branch of this thread, there is a way for
PHP to access the body of the POST request via standard input.  Making
available the body of the request was already defined for CGI/1.1
<http://tools.ietf.org/html/draft-robinson-www-interface-00> (section
8), so the body *might* be generally available for server-side
applications, even if they are not implemented as CGI/1.1 applications
(like mod_php).

That's not to argue, that "application/x-www-form-urlencoded" is most
probably the safest and most convenient Content-Type for POST requests.

> Incidentally, the current HTML5 Working Draft places more constraints there, 
> specifying "text/plain" as one of only three media types that are to be 
> supported there. [8]  So apparently there are some, probably newer, server-
> side applications that support it.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#15545

On Thu, 23 Aug 2012 15:00:37 -0700, Gene Wirchenko wrote:

> Dear JavaScripters:
> 
>      I am trying to pass data back and forth using XMLHttpRequest.  I
> have run into a few issues.  The first one is the most important.
> 
>   1) I can not get POST to work according to various documentation I
> have found on the Web.
> 
>      Suppposedly, the .open() and .send() would be
>           oRequest.open("POST",Url,true); oRequest.send(DataToSend);
> but with this, at the server end, the .QueryString value is ""
> regardless of what was supposedly sent.
> 
>      I have found that using the GET style of
>           oRequest.open("POST",Url+"?"+DataToSend,true);
>           oRequest.send();
> does work.  At least, it appears to.
> 
>      Am I doing something wrong, or is the documentation wrong?
> 
>   2) What should I do for escaping of data?  Going to the server, any
> line breaks get eaten somewhere so I use escape() at browser and
> unescape() at server.  Going from server to browser, line break are not
> eaten.  Does this mean that I do not have to escape()/unescape()
> on the trip back?
> 
>      Are escape() and unescape() the correct functions to use?
> 
> Sincerely,
> 
> Gene Wirchenko

Here's some example javascript code from something I did:

Firstly the getxhr function:

// get a new XMLHttpRequest object
function getxhr() {
  if (xhrFailOnce) return null;
  var xhr;
  if (typeof XMLHttpRequest == 'undefined') {
    try { // preferred
      xhr = new ActiveXObject("Msxml2.XMLHTTP.6.0");
    }
    catch (e1) {
      try { // best fallback
        xhr = new ActiveXObject("Msxml2.XMLHTTP.3.0");
      }
      catch (e2) {
        try { // last one to try
          xhr = new ActiveXObject("Microsoft.XMLHTTP");
        }
        catch (e3) {
          xhr = false;
        }
      }
    }
  } else {
    xhr = new XMLHttpRequest();
  }
  if (!xhr) {
    if (!xhrFailOnce) {
      alert("Sorry, your browser does not support scripting features used 
on this website.");
      xhrFailOnce = true;
    }
    xhr = null;
  }
  return xhr;
}

var data = "cartid=" + cartid + "&qty=" + qty.toString();
// use an XMLHttpRequest to update the cart
var xmlhttp = getxhr();
if (!xmlhttp) return;
xmlhttp.open("POST","update_cart.php",false);
//Send the proper header information along with the request
xmlhttp.setRequestHeader("Content-type", "application/x-www-form-
urlencoded");
xmlhttp.setRequestHeader("Content-length", data.length);
xmlhttp.setRequestHeader("Connection", "close");
xmlhttp.send(data);

This code is for talking to php, but I don't see why any other backend 
would be different from the js viewpoint - although obviously the code in 
a VB backend will be somewhat different to that in a php backend.

But the backend should see this as the same as it would a <form 
method="post" action="blah"> </form>

Note that the data is of the format 
key1=value1&key2=value2&key3=value3.....

Note also that if your data values are taken from form fields, you will 
probably need to apply some level of validation / sanitising / escaping 
in the js, see <http://www.w3.org/TR/html401/interact/
forms.html#h-17.13.4.1>

"application/x-www-form-urlencoded

This is the default content type. Forms submitted with this content type 
must be encoded as follows:

1.    Control names and values are escaped. Space characters are replaced 
by `+', and then reserved characters are escaped as described in 
[RFC1738], section 2.2: Non-alphanumeric characters are replaced by `%HH', 
a percent sign and two hexadecimal digits representing the ASCII code of 
the character. Line breaks are represented as "CR LF" pairs (i.e., `%0D%
0A').

2.    The control names/values are listed in the order they appear in the 
document. The name is separated from the value by `=' and name/value 
pairs are separated from each other by `&'."

As for how the data presents itself server side, well in php it's in the 
$_POST array as $_POST["key1"], $_POST["key2"], $_POST["key3"] ...

A very quick search of google suggests that:

<%
Dim val1, val2, val3
val1 = Request.Form("key1")
val2 = Request.Form("key2")
val3 = Request.Form("key3")
%>

might be the way to read the post values in the ASP VB that handles the 
XMLHttpRequest.

Rgds

Denis McMahon

[toc] | [prev] | [next] | [standalone]

#15546

On Thursday, August 23, 2012 5:00:37 PM UTC-5, Gene Wirchenko wrote:
> Dear JavaScripters:
> 
> 
> 
>      I am trying to pass data back and forth using XMLHttpRequest.  I
> 
> have run into a few issues.  The first one is the most important.
> 
> 
> 
>   1) I can not get POST to work according to various documentation I
> 
> have found on the Web.
> 
> 
> 
>      Suppposedly, the .open() and .send() would be
> 
>           oRequest.open("POST",Url,true);
> 
>           oRequest.send(DataToSend);
> 
> but with this, at the server end, the .QueryString value is ""
> 
> regardless of what was supposedly sent.
> 
> 
> 
>      I have found that using the GET style of
> 
>           oRequest.open("POST",Url+"?"+DataToSend,true);
> 
>           oRequest.send();
> 
> does work.  At least, it appears to.
> 
> 
> 
>      Am I doing something wrong, or is the documentation wrong?
> 
> 
> 
>   2) What should I do for escaping of data?  Going to the server, any
> 
> line breaks get eaten somewhere so I use escape() at browser and
> 
> unescape() at server.  Going from server to browser, line break are
> 
> not eaten.  Does this mean that I do not have to escape()/unescape()
> 
> on the trip back?
> 
> 
> 
>      Are escape() and unescape() the correct functions to use?
> 

...
xhr.onreadystatechange = handler;
xhr.open('POST', url);
xhr.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
xhr.send('userName=' + encodeURIComponent(userName));
...

[toc] | [prev] | [next] | [standalone]

#15549

"Gene Wirchenko" <genew@ocis.net> schreef in bericht 
news:429d38h112ptste9sp22ks8sqk9cgumo7r@4ax.com...
> Dear JavaScripters:
>
>     I am trying to pass data back and forth using XMLHttpRequest.  I
> have run into a few issues.  The first one is the most important.
>
>  1) I can not get POST to work according to various documentation I
> have found on the Web.
>

I use:
  var transmit = function(txt){

   // d2w.appID is a global with an ID string unique for this client
    asyncRequestor.open("POST",d2w.appID,true);
    asyncRequestor.setRequestHeader("Content-type","application/x-www-form-urlencoded");
    asyncRequestor.send(txt);
  };


At the server end, using Indy/Delphi, I get the txt from HTTPrequestInfo.
Tom

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web