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

Groups > comp.lang.php > #14892 > unrolled thread

Newby neds help

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

Contents

  Newby neds help F. George McDuffee <gmcduffee@mcduffee-associates.us> - 2015-02-07 14:38 -0600
    Re: Newby neds help Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-02-07 16:31 -0500
    Re: Newby neds help "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-07 23:30 +0100
    Re: Newby neds help Tim Streater <timstreater@greenbee.net> - 2015-02-07 22:36 +0000
    Re: Newby neds help Denis McMahon <denismfmcmahon@gmail.com> - 2015-02-08 00:06 +0000
      Re: Newby neds help "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-08 01:29 +0100
        Re: Newby neds help Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-07 20:22 -0500
          Re: Newby neds help "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-08 02:33 +0100
            Re: Newby neds help Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-07 20:54 -0500
        Re: Newby neds help Denis McMahon <denismfmcmahon@gmail.com> - 2015-02-08 13:27 +0000
          Re: Newby neds help "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-08 15:22 +0100
            Re: Newby neds help Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-08 21:58 +0100
              Re: Newby neds help "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-08 22:56 +0100
                Re: Newby neds help Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-08 23:36 +0100
                  Re: Newby neds help "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-09 00:14 +0100
                    Re: Newby neds help Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-09 00:42 +0100
                      Re: Newby neds help "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-09 00:58 +0100
                  Re: Newby neds help Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2015-02-09 00:30 +0100
                    Re: Newby neds help "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-10 00:53 +0100
            Re: Newby neds help Denis McMahon <denismfmcmahon@gmail.com> - 2015-02-08 21:46 +0000
              Re: Newby neds help "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-09 00:40 +0100
                Re: Newby neds help Denis McMahon <denismfmcmahon@gmail.com> - 2015-02-09 19:34 +0000
                  HTTP (was: Newby neds help) "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-10 02:04 +0100
          Re: Newby neds help F. George McDuffee <gmcduffee@mcduffee-associates.us> - 2015-02-08 20:06 -0600
            Re: Newby neds help Matthew Carter <m@ahungry.com> - 2015-02-08 21:55 -0500
              Re: Newby neds help F. George McDuffee <gmcduffee@mcduffee-associates.us> - 2015-02-09 00:13 -0600
            Re: Newby neds help Tim Streater <timstreater@greenbee.net> - 2015-02-09 09:46 +0000
            Re: Newby neds help "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-10 01:14 +0100
      Re: Newby needs help F. George McDuffee <gmcduffee@mcduffee-associates.us> - 2015-02-07 19:29 -0600
        Re: Newby needs help "Christoph M. Becker" <cmbecker69@arcor.de> - 2015-02-08 02:40 +0100
        Re: Newby needs help Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-02-07 21:36 -0500
    Re: Newby neds help Jerry Stuckle <jstucklex@attglobal.net> - 2015-02-07 21:33 -0500
    Re: Newby neds help Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-02-09 20:02 -0500

Page 1 of 2  [1] 2  Next page →

#14892 — Newby neds help

About me: Nyme Unka_George. I am a long time lurker on this
group and a retired academic with some obsolete web design
experience [Front Page].  I am attempting to learn HTML5,
Javascrip, and PHP at the same time, and have made some
progress [got a cut and paste hit-counter working].

General problem for group: I can't get a tab delimited
formatted string to transfer from a client side web survey
which uses Javascript to score a survey [which is working
see  http://mcduffee-associates.us/MDI05g.html ] to a server
side PHP program which will append the tab delimited
formatted string to an existing tab delimited file [which is
also working, using inline dummy data.  The PHP program is
shown below.  PHP is running locally on XAMPP v3.2.1  

Background: Survey is from the World Health Organization and
measures depression.  The survey has been validated across a
number of cultures.  My interest is in determining the
extent and degree of depression in rural/micro urban areas
as part of RED [Rural Economic Development] effort, and by
doing multiple regression analysis of the depression and
demographic data determine how much, if any, correlation
exists job status, housing, living arrangements, length of
commute, job tenure, type of housing, etc.  This is
important because depression, both “overt” which this survey
attempts to measure, and “masked” depression have been shown
to closely associated with “learned helplessness,” [subject
of another survey in preparation] which if prevalent will
prevent a community growth/development even when
opportunities are available.  Therefore this must be
corrected, either before, or concurrent with, any economic
development efforts if these are to succeed.  My web RED web
page, along with some earlier versions on the survey in
Visual Basic can be seen at
http://mcduffee-associates.us/RED/redmain.htm   

what I think is the important part of the Javscript program
is
***************************
	 		function SendString( ){
	 		// function to move client datastring to server for
appending to file
	 		// set to local server test file -- will require
real file and refactoring
	 		// MDItest.php not set to reveive data yet.
	 		alert("got to start of SendString( )");
	 		xmlhttp.open("POST","MDItest.php",true);
                  xmlhttp.send(window.upstring);
                  // no xmlhttp.close( );
                  alert("got through open/send of
SendString( )");
	 		}
***************************   

 a fragment of how the the tab delimited string is
constructed 
********************  
			Qloc = document.getElementById("textarea1");
				// Qval = Qloc.options[Qloc].innerHTML;
				Qval =
document.getElementById("textarea1").value;
				window.upstring = window.upstring + '\t"' + Qval
+ '"';
			Qloc = document.getElementById("input1");
				Qval = document.getElementById("input1").value;
				window.upstring = window.upstring + '\t"' + Qval
+ '"';
			// append local time
			window.upstring = window.upstring +'\t"' + t + '"';
			//
			// append client browser information
				var NavResult = "test";
				NavResult = navigator.userAgent.substr(0,60);
				// alert(NavResult);
				window.upstring = window.upstring + "\t\"" +
NavResult + "\"";
************************  
	 		



PHP program to append survey data to existing file server
file
***********************************
<?php
// Work In Progress !!!!!!!!!!!!!!!!!!!
// cut and paste from web
// 21 June 14 GmcD
// how called in HTML: <script
src="http://mcduffee-associates.us/PHP/MDI/MDItab.php?MDIstring=window.upload"></script>
// ?? no quotes because I want variable contents, not
variable name window.upload
// <script src= MyURLstring></script> 
$MDIstring = $_GET[MDIstring]
print('got to MDItab.php' );
// Did data string load??
if ( ! isset($_GET['MDIstring']) )  // quotes?
{
	die('ERROR: 'PROBLEMS WITH UpYouGo/MDItab.php');
} // end data xfer check
 
flush( );
ob_flush( );

// show string on client browser
print(MDIstring);
// decode $MDIstring and restore special characters
$MDIstring = urldecode($MDIstring); // may be unnecessary as
get is used
print(MDIstring);
flush( );
ob_flush( );




AppendMDILine($MDIstring);

function AppendMDILine($MDIstring) {
	// alternate file to append form data 
	// string is tab delimited quoted form data string
	// append client IP
	// add client IP and newline
	// \t = tab ; \n = new line line feed ; \r = carriage
return
	// add ip temp commented out add quote + cr/lf
	$MDIstring = $MDIstring +'\"\r\n'
	// following line commented out for test
	// $MDIstring = $MDIstring + '\t"' +  get_client_ip( ) +
'"\r\n';
	//
	// directly writes to file.
	// need to create directories and check path
	// $handle =
fopen('http://www.mcduffee-associates.us/post/mdi/mdidta.tsv',
'ab');
	// commented out for test
	$handle = fopen('www/web_surveys/mdidta.tsv' , 'ab' );
	// 'ab' is append binary, may need to change to 'at' for
/cr/lf xlation
	// int fwrite( resource $handle , string $string [, int
$length ] )
	fwrite( $handle,  $MDIstring );
	// bool fclose ( resource $handle )
	fclose($handle);
}  // end AppendMDILine()
 
 //
 //
 // Function to get the client ip address
function get_client_ip() {
    $ipaddress = '';
    if (getenv('HTTP_CLIENT_IP'))
        $ipaddress = getenv('HTTP_CLIENT_IP');
    else if(getenv('HTTP_X_FORWARDED_FOR'))
        $ipaddress = getenv('HTTP_X_FORWARDED_FOR');
    else if(getenv('HTTP_X_FORWARDED'))
        $ipaddress = getenv('HTTP_X_FORWARDED');
    else if(getenv('HTTP_FORWARDED_FOR'))
        $ipaddress = getenv('HTTP_FORWARDED_FOR');
    else if(getenv('HTTP_FORWARDED'))
        $ipaddress = getenv('HTTP_FORWARDED');
    else if(getenv('REMOTE_ADDR'))
        $ipaddress = getenv('REMOTE_ADDR');
    else
        $ipaddress = 'UNKNOWN';
 
    return $ipaddress;
} // end get_client_ip()

  
?>
**********************  

FWIW:  The accumulated tab delimited data file will be
downloaded using FTP, and imported into Excel.  I have a
very nice inexpensive multiple regression analysis add-in
called win-stat http://www.winstat.com/ ,  with which I am
familiar, and which produces publication quality graphs,
which can be output as a pdf file for easy web publication.
In the unlikely event the dataset gets too big for excel,
there is always R.
-- 
Unka' George

"Gold is the money of kings, 
silver is the money of gentlemen, 
barter is the money of peasants, 
but debt is the money of slaves"
 
-Norm Franz, "Money and Wealth in the New Millenium" 

[toc] | [next] | [standalone]

#14893

On Saturday February 7 2015 15:38, in comp.lang.php, "F. George McDuffee"
<gmcduffee@mcduffee-associates.us> wrote:

This /is/ comp.lang.php, and I'm not expert in Ajax calls or javascript in
general, so my answer may have gaps.

> what I think is the important part of the Javscript program
> is
> ***************************
> function SendString( ){
> // function to move client datastring to server for
> appending to file
> // set to local server test file -- will require
> real file and refactoring
> // MDItest.php not set to reveive data yet.
> alert("got to start of SendString( )");
> xmlhttp.open("POST","MDItest.php",true);

Is this Javascript not asking for a POST http operation? With the posted
values to follow in the request data?

>                   xmlhttp.send(window.upstring);
>                   // no xmlhttp.close( );
>                   alert("got through open/send of
> SendString( )");
> }
> ***************************
[snip]
> PHP program to append survey data to existing file server
> file
> ***********************************
> <?php
> // Work In Progress !!!!!!!!!!!!!!!!!!!
[snip]
> $MDIstring = $_GET[MDIstring]

This line looks to me to have multiple errors.
 1) ITYM $_GET['MDIstring']
 2) statement is missing the terminating semicolon.
P'haps the PHP page is erroring out here, before getting to the processing.

In any case, why are you checking the ($_GET) "GET" variables? You aren't
sending any from your Javascript. You should check the ($_POST) "POST"
variables, or change your Javascript to build a complete URL (with your
MDIstring named) and xmlhttp.open("GET","MDItest.php?MDIstring=...",TRUE).

> print('got to MDItab.php' );
> // Did data string load??
> if ( ! isset($_GET['MDIstring']) )  // quotes?
> {
> die('ERROR: 'PROBLEMS WITH UpYouGo/MDItab.php');
> } // end data xfer check

Still checking $_GET for something that's not going to be there.
See above comments.

> flush( );
> ob_flush( );
> 
> // show string on client browser
> print(MDIstring);
> // decode $MDIstring and restore special characters
> $MDIstring = urldecode($MDIstring); // may be unnecessary as
> get is used
> print(MDIstring);
> flush( );
> ob_flush( );
[snip]
>   
> ?>
> **********************

Try making the Javascript and PHP agree on how parameters are to be passed.
They should both be POST or GET.

If they are both GET, then the Javascript must write the parameters into the
URL before the open(),

If they are both POST, then the Javascript must write the parameters to the
as separate lines after the open()

HTH
-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#14894

F. George McDuffee wrote:

> General problem for group: I can't get a tab delimited
> formatted string to transfer from a client side web survey
> which uses Javascript to score a survey [which is working
> see  http://mcduffee-associates.us/MDI05g.html ] to a server
> side PHP program which will append the tab delimited
> formatted string to an existing tab delimited file [which is
> also working, using inline dummy data.  The PHP program is
> shown below.  PHP is running locally on XAMPP v3.2.1  

I suggest that you do not use JavaScript to construct and send an
already prepared string to the server, but rather rely on HTML means,
namely forms, to post the relevant information.  The obvious benefit is
that the survey is also usable for those who don't have JavaScript
enabled/available.  Another advantage is that it is much easier to
validate the posted data on the server before you store them in a file.
 Validation of the data on the server is necessary to avoid submission
of data by other means than offered on your website (for instance, one
could easily use cURL to send arbitrary data).

-- 
Christoph M. Becker

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

#14895

In article <6rtcdahf5gqka5aavks1kub18uoqnd7ajl@4ax.com>, F. George
McDuffee <gmcduffee@mcduffee-associates.us> wrote:

>About me: Nyme Unka_George. I am a long time lurker on this
>group and a retired academic with some obsolete web design
>experience [Front Page].  I am attempting to learn HTML5,
>Javascrip, and PHP at the same time, and have made some
>progress [got a cut and paste hit-counter working].

That's a lot to learn all in one go. Why don't you start with something
simple, make it work, understand how it works and why, and build up
from there.

You could look at:

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

for a simple example.

-- 
"If you're not able to ask questions and deal with the answers without feeling 
that someone has called your intelligence or competence into question, don't 
ask questions on Usenet where the answers won't be carefully tailored to avoid
tripping your hair-trigger insecurities."                  - D M Procida, UCSM

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

#14896

On Sat, 07 Feb 2015 14:38:22 -0600, F. George McDuffee wrote:

> General problem for group: I can't get a tab delimited formatted string
> to transfer from a client side web survey

Sounds like you're trying to reinvent the wheel but not sure how to do it.

Trying to implement your own method of data transfer (eg tab delimited 
formatted string which you then need to parse on the server) to pass data 
from the client to the server when html and the http protocol already 
have built in methods to handle the data transfer and php provides a 
mechanism for easy access to the string data is a waste of time and 
effort.

Assuming your "client side web survey" uses typical html input elements, 
select / option lists and textareas etc, you don't need any javascript at 
all to prepare the data for the transmission to the server, you can just 
wrap the user input up in a form and use the html / http features to 
transfer the data fields to your server.

Then use php to read the submitted user data from the $_POST or $_GET 
array (depending which form method you use) and process it into your 
survey, using appropriate data validation and verification.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#14897

Denis McMahon wrote:

> Then use php to read the submitted user data from the $_POST or $_GET 
> array (depending which form method you use) and process it into your 
> survey, using appropriate data validation and verification.

It seems to be noteworthy that the form method should not be subject to
an arbitrary choice of the developer, but rather should comply to RFC
7231 section 4[1].  Therefore a GET request would be inappropriate, denis.

[1] <http://tools.ietf.org/html/rfc7231#section-4>

-- 
Christoph M. Becker

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

#14898

On 2/7/2015 7:29 PM, Christoph M. Becker wrote:
> Denis McMahon wrote:
> 
>> Then use php to read the submitted user data from the $_POST or $_GET 
>> array (depending which form method you use) and process it into your 
>> survey, using appropriate data validation and verification.
> 
> It seems to be noteworthy that the form method should not be subject to
> an arbitrary choice of the developer, but rather should comply to RFC
> 7231 section 4[1].  Therefore a GET request would be inappropriate, denis.
> 
> [1] <http://tools.ietf.org/html/rfc7231#section-4>
> 

Except you didn't read section 4.1:

"All general-purpose servers MUST support the methods GET and HEAD.
All other methods are OPTIONAL."

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#14900

Jerry Stuckle wrote:

> On 2/7/2015 7:29 PM, Christoph M. Becker wrote:
>
>> It seems to be noteworthy that the form method should not be subject to
>> an arbitrary choice of the developer, but rather should comply to RFC
>> 7231 section 4[1].  Therefore a GET request would be inappropriate, denis.
>>
>> [1] <http://tools.ietf.org/html/rfc7231#section-4>
> 
> Except you didn't read section 4.1:
> 
> "All general-purpose servers MUST support the methods GET and HEAD.
> All other methods are OPTIONAL."

Red herring.

-- 
Christoph M. Becker

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

#14902

On 2/7/2015 8:33 PM, Christoph M. Becker wrote:
> Jerry Stuckle wrote:
> 
>> On 2/7/2015 7:29 PM, Christoph M. Becker wrote:
>>
>>> It seems to be noteworthy that the form method should not be subject to
>>> an arbitrary choice of the developer, but rather should comply to RFC
>>> 7231 section 4[1].  Therefore a GET request would be inappropriate, denis.
>>>
>>> [1] <http://tools.ietf.org/html/rfc7231#section-4>
>>
>> Except you didn't read section 4.1:
>>
>> "All general-purpose servers MUST support the methods GET and HEAD.
>> All other methods are OPTIONAL."
> 
> Red herring.
> 

ROFLMAO.  It's just as accurate as the paragraph you cited.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#14907

On Sun, 08 Feb 2015 01:29:17 +0100, Christoph M. Becker wrote:

> Denis McMahon wrote:

>> Then use php to read the submitted user data from the $_POST or $_GET
>> array (depending which form method you use) and process it into your
>> survey, using appropriate data validation and verification.

> It seems to be noteworthy that the form method should not be subject to
> an arbitrary choice of the developer, but rather should comply to RFC
> 7231 section 4[1].  Therefore a GET request would be inappropriate,
> denis.

A POST request may indeed be more appropriate than a GET request, that is 
a decision for the developer to make. However, there is no rule that 
states "form data must only be transferred to the server using POST".

Up to the OP to choose the mechanism that best suits his data.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

#14910

Denis McMahon wrote:

> On Sun, 08 Feb 2015 01:29:17 +0100, Christoph M. Becker wrote:
> 
>> Denis McMahon wrote:
> 
>>> Then use php to read the submitted user data from the $_POST or $_GET
>>> array (depending which form method you use) and process it into your
>>> survey, using appropriate data validation and verification.
> 
>> It seems to be noteworthy that the form method should not be subject to
>> an arbitrary choice of the developer, but rather should comply to RFC
>> 7231 section 4[1].  Therefore a GET request would be inappropriate,
>> denis.
> 
> A POST request may indeed be more appropriate than a GET request, that is 
> a decision for the developer to make. However, there is no rule that 
> states "form data must only be transferred to the server using POST".

No, of course there is no such rule.  It would not make much sense, for
example, to submit data of a search form via a POST request.  On the
other hand, the data for a survey which are going to be stored on the
server (what is what the OP wants to accomplish), should not be
submitted via a GET request.

-- 
Christoph M. Becker

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

#14912

Christoph M. Becker wrote:

> Denis McMahon wrote:
>> A POST request may indeed be more appropriate than a GET request, that is
>> a decision for the developer to make. However, there is no rule that
>> states "form data must only be transferred to the server using POST".
> 
> No, of course there is no such rule.

There are, however, strong recommendations in the HTTP/1.1 Specification as 
to when verbs SHOULD NOT be used.  (Questions about this can be part of the 
ZCE PHP exam.)

<http://tools.ietf.org/html/rfc2616#section-9.1>

> It would not make much sense, for example, to submit data of a search form
> via a POST request.

Yes, it would.  Apparently you are unaware of the URI length limit imposed 
by browsers, especially Internet Explorer, and of search-by-resource.

<http://stackoverflow.com/a/417184/855543>
<http://www.google.com/insidesearch/features/images/searchbyimage.html>

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#14916

Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
> 
>> Denis McMahon wrote:
>>> A POST request may indeed be more appropriate than a GET request, that is
>>> a decision for the developer to make. However, there is no rule that
>>> states "form data must only be transferred to the server using POST".
>>
>> No, of course there is no such rule.
> 
> There are, however, strong recommendations in the HTTP/1.1 Specification as 
> to when verbs SHOULD NOT be used.  (Questions about this can be part of the 
> ZCE PHP exam.)
> 
> <http://tools.ietf.org/html/rfc2616#section-9.1>

<http://tools.ietf.org/html/rfc7231#section-4.1> still seems more
appropriate nowadays.

>> It would not make much sense, for example, to submit data of a search form
>> via a POST request.
> 
> Yes, it would.  Apparently you are unaware of the URI length limit imposed 
> by browsers, especially Internet Explorer, and of search-by-resource.

Indeed, I had not considered search-by-resource (thanks for the
pointer), but rather a simple search box (such as used by the Google web
search).  I do not expect anybody to type in several hundrets of
characters in such a field, so the 2000 character limit of old IE should
be no problem even for UTF-8 character encoding.

A nice (side-)effect of using a GET request would be that the URI could
be easily shared and bookmarked.

-- 
Christoph M. Becker

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

#14917

Christoph M. Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> <http://tools.ietf.org/html/rfc2616#section-9.1>
> 
> <http://tools.ietf.org/html/rfc7231#section-4.1> still seems more
> appropriate nowadays.

ACK.

>>> It would not make much sense, for example, to submit data of a search
>>> form via a POST request.
>> Yes, it would.  Apparently you are unaware of the URI length limit
>> imposed by browsers, especially Internet Explorer, and of
>> search-by-resource.
> 
> Indeed, I had not considered search-by-resource (thanks for the
> pointer), but rather a simple search box (such as used by the Google web
> search).  I do not expect anybody to type in several hundrets of
> characters in such a field, so the 2000 character limit of old IE

The referenced answer at Stack Overflow was updated in September 2014; it 
states that IE 10 exhibits a similar problem.  While that requires 
verification, I do not consider IE 10, released in September 2012 and still 
updated, to be old.  The problem with IE 10 is said to be merely in the 
multibar, but that might be enough so that the resource cannot be 
bookmarked.

Certainly search engine’s, especially Google’s, restriction to 1855 and 2047 
characters, respectively, is to be considered.

> should be no problem even for UTF-8 character encoding.

The problem gets worse if Unicode characters beyond the ASCII range are used 
because those require at least 6 characters in their URI-encoded form 
(“%xx%xx”), dividing the number of available characters by 6 in the worst 
case.

In any case, you are overlooking the distinct possibility of a not-so-simple 
search form (including, but not limited to, those that support search-by-
resource).  For example, <http://akas.imdb.com/search/title> uses a POST 
request, and that is good so.

> A nice (side-)effect of using a GET request would be that the URI could
> be easily shared and bookmarked.

And sensitive information could be stored client-side without sufficient 
protection.

A combination of POST data and URI parameters appears to be appropriate, but 
it cannot be achieved without client-side DOM scripting if the values of the 
parameters that are to occur in the URI are to be variable.

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#14918

Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
> 
>> [...] I do not expect anybody to type in several hundrets of
>> characters in such a field, so the 2000 character limit of old IE
> 
> The referenced answer at Stack Overflow was updated in September 2014; it 
> states that IE 10 exhibits a similar problem. [...]

Thanks.  I should have read the referenced Stack Overflow answer instead
of relying on obviously wrong information (I thought this limit had been
removed with IE 9).

>> should be no problem even for UTF-8 character encoding.
> 
> The problem gets worse if Unicode characters beyond the ASCII range are used 
> because those require at least 6 characters in their URI-encoded form 
> (“%xx%xx”), dividing the number of available characters by 6 in the worst 
> case.

Therefore I've written "several hundrets" (should have been "hundreds",
of course).  However, AFAIK a UTF-8 encoded string will be URI-encoded
octet-wise, so a single code point could occupy up to 12 characters in
the URI, what would only be sufficient for roughly 150 such code points.

> In any case, you are overlooking the distinct possibility of a not-so-simple 
> search form (including, but not limited to, those that support search-by-
> resource).  For example, <http://akas.imdb.com/search/title> uses a POST 
> request, and that is good so.

ACK.  I should have better written a "simple search form" in the first
place.

>> A nice (side-)effect of using a GET request would be that the URI could
>> be easily shared and bookmarked.
> 
> And sensitive information could be stored client-side without sufficient 
> protection.

It seems to me that sensitive information does neither belong in an URI,
nor in the payload of an unencrypted HTTP connection.

-- 
Christoph M. Becker

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

#14921

Christoph M. Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Christoph M. Becker wrote:
>>> should be no problem even for UTF-8 character encoding.
>> The problem gets worse if Unicode characters beyond the ASCII range are
>> used because those require at least 6 characters in their URI-encoded
>> form (“%xx%xx”), dividing the number of available characters by 6 in the
>> worst case.
> 
> Therefore I've written "several hundrets" (should have been "hundreds",
> of course).  However, AFAIK a UTF-8 encoded string will be URI-encoded
> octet-wise,

If you mean by this that the code point of each character is determined,
then the code point’s UTF-8 code sequence is calculated, and then each 
octet’s hexadecimal (uppercased) string representation is preceded by ”%”, 
then you are correct.

> so a single code point could occupy up to 12 characters in the URI, what 
> would only be sufficient for roughly 150 such code points.

Yes, up to 4 UTF-8 code units per code sequence are specified in the current  
“Unicode Standard, Version 7.0” [1].  Hence “*at least* 6”.

>>> A nice (side-)effect of using a GET request would be that the URI could
>>> be easily shared and bookmarked.
>> And sensitive information could be stored client-side without sufficient
>> protection.
> 
> It seems to me that sensitive information does neither belong in an URI,
> nor in the payload of an unencrypted HTTP connection.

ACK.

________
[1] <http://www.unicode.org/versions/Unicode7.0.0/>
-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#14923

Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
> 
>> Therefore I've written "several hundrets" (should have been "hundreds",
>> of course).  However, AFAIK a UTF-8 encoded string will be URI-encoded
>> octet-wise,
> 
> If you mean by this that the code point of each character is determined,
> then the code point’s UTF-8 code sequence is calculated, and then each 
> octet’s hexadecimal (uppercased) string representation is preceded by ”%”, 
> then you are correct.

Yes, that is what I meant.  Thanks for the clarification. :)

>> so a single code point could occupy up to 12 characters in the URI, what 
>> would only be sufficient for roughly 150 such code points.
> 
> Yes, up to 4 UTF-8 code units per code sequence are specified in the current  
> “Unicode Standard, Version 7.0” [1].  Hence “*at least* 6”.

ACK.

-- 
Christoph M. Becker

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

#14919

Thomas 'PointedEars' Lahn wrote:

> A combination of POST data and URI parameters appears to be appropriate,
> but it cannot be achieved without client-side DOM scripting if the values
> of the parameters that are to occur in the URI are to be variable.

Correction: It can be achieved using POST/Redirect/GET (PRG) and a server-
side session in which to store the sensitive information.  All parameter 
values would be in the POST message body, but the URI for the GET request 
would contain only those that do not constitute sensitive information.

Quickhack:

  session_name('safesearch');
  session_start();

  if (count($_POST) > 0)
  {
    $p =& $_SESSION['POST_data'];
    $p = [];
    array_push($p, $_POST);

    header($_SERVER['SERVER_PROTOCOL'] . ' 303 See Other');
    header(
        "Location: {$SERVER['SCRIPT_NAME']}"
      . '?' . implode('&', get_public_parameters($_POST)));
    exit(0);
  }

  session_regenerate_id();

  /* generate output using $_SESSION['POST_data'] */

-- 
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#14930

Thomas 'PointedEars' Lahn wrote:

> Thomas 'PointedEars' Lahn wrote:
> 
>> A combination of POST data and URI parameters appears to be appropriate,
>> but it cannot be achieved without client-side DOM scripting if the values
>> of the parameters that are to occur in the URI are to be variable.
> 
> Correction: It can be achieved using POST/Redirect/GET (PRG) and a server-
> side session in which to store the sensitive information.  All parameter 
> values would be in the POST message body, but the URI for the GET request 
> would contain only those that do not constitute sensitive information.

An interesting solution. :)

>     $p =& $_SESSION['POST_data'];
>     $p = [];
>     array_push($p, $_POST);

Wouldn't the following be equivalent?

  $_SESSION['POST_data'] = $_POST;

>     header($_SERVER['SERVER_PROTOCOL'] . ' 303 See Other');

I have not been aware of SERVER_PROTOCOL; might come in handy -- thanks.
 However, I'm not sure if it's okay to use it in this case.  AFAIK 303
is only specified for HTTP/1.1, but not for HTTP/1.0.  I still have to
catch up on HTTP/2.0, though.

>     header(
>         "Location: {$SERVER['SCRIPT_NAME']}"

While RFC 7321 specifies that the value of the Location header field is
an URI-reference, RFC 2616 says it must be an absoluteURI.  I had some
problems in the past with older IIS (6?), where a relativeURI was not
properly processed (server-side!).  This might not be relevant anymore,
but still I'd prefer to use an absoluteURI.

-- 
Christoph M. Becker

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

#14914

On Sun, 08 Feb 2015 15:22:29 +0100, Christoph M. Becker wrote:

> No, of course there is no such rule.  It would not make much sense, for
> example, to submit data of a search form via a POST request.  On the
> other hand, the data for a survey which are going to be stored on the
> server (what is what the OP wants to accomplish), should not be
> submitted via a GET request.

That's your opinion of course, based on your personal interpretation of 
various documents.

In so far as http and server side scripting is concerned, it matters very 
little to either the browser or the web server whether data is 
transferred using the get or post methods, subject to any technical 
limitations relevant to the chosen request method. The decision is often 
better based on the numbers and types of data fields being transferred, 
and the volume of the data, rather than the eventual use to which the 
data will be put. It is the place of the person designing the system to 
determine which is most appropriate for their application. I am sure 
however that the OP will consider your unsolicited opinion on the matter 
with whatever gravity[1] he feels it deserves.

Me, I'm not going to try and force what I think is the most appropriate  
method down the OPs throat. That wasn't the question he asked, and even 
if it was, I would only offer my opinion as to the best method to use, 
not tell him what he must do. If he asks which method I think would be 
best, I'll tell him which I would probably choose in his position, but I 
don't think it's my place to tell him that he must use a specific method.

[1] gravity - the force that transfers poop from my butt to the toilet.

-- 
Denis McMahon, denismfmcmahon@gmail.com

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web