Newby neds help

[F. George McDuffee]

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"

[Lew Pitcher]

On Saturday February 7 2015 15:38, in comp.lang.php, "F. George McDuffee"
<gmcd...@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

[Christoph M. Becker]

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

[Denis McMahon]

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, denismf...@gmail.com

[Christoph M. Becker]

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

[Jerry Stuckle]

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
jstu...@attglobal.net
==================

[F. George McDuffee]

Thanks to everyone who is responding.

>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.

Indeed!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! This was a piece of
cake when Front Page was working.

>
>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.

Don't want to invent anything, just use $_POST or $_GET to
communicate with PHP. Tab delimited strings used because it
is easy to import data in this format into excel. Server
does no processing other than converting URL safe string
back to standard ascii and appending (or creating) tab
delimited flat ascii file, thus no need to parse.

>
>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.

Javascript needed to score the survey and display message to
user based on that total score. Survey is "live" [feel free
to try it] but accumulates no data. 2 Alert()s used to
display the tab delimited and URL safe strings
[window.upstring=encodeURIComponent(window.upstring)] the
program generates from the user inputs. This part seems to
be working fine
http://mcduffee-associates.us/MDI05g.html

>
>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.

My problem is I can't get either post or get to do anything.
Because of the possibility of user entering significant
amounts of text would like to use $_POST If you try program
it displays the tab delimited and URICencoded strings ok and
tries to post from the error message. I can't seem to get
around this transfer problem.

Don't want/need to do any processing on the server. Just
want to convert window.upstring string back to standard tab
delimited ascii using string urldecode(string $str)
http://tinyurl.com/luls3u and accumulate data in tab
delimited flat ascii file by appending to end of existing
file to be FTP downloaded and imported into excel for local
processing/analysis.

How/why did this get so complicated???????????????


Unka' George

[Christoph M. Becker]

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

[Christoph M. Becker]

F. George McDuffee wrote:

> How/why did this get so complicated???????????????

Because you're trying to reinvent the wheel.

--
Christoph M. Becker

[Jerry Stuckle]

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

[Jerry Stuckle]

<snip>

First of all, forget Christoph M. Becker's comments. He's just a troll,
only capable of (mis)quoting standards and trolling.

As for your problem - there are several ways of doing this. Personally,
I would just POST the form to the server and have the PHP code create
the tab-delimited string. Even better would be to use fputcsv() to
write the string to a .csv file.

You can get what you have here to work, but it's going to take a bit of
debugging. Your first step should be to separate your attempt into two
separate pieces.

You didn't post all of the javascript (which would be off-topic here,
anyway), but my suggestion would be to get that piece working first.
Lew already gave you some good comments on problems in your javascript
code; you should be able to get more help on that part from
comp.lang.javascript.

As for debugging - create a PHP page which simply saves the data it gets
to a file - nothing more. Now strip your javascript to the absolute
minimum required (i.e. send one field, unformateed), and get that
working. Now add additional code, one piece at a time, and get it working.

Alternatively, use a javascript debugger such as Firebug on Firefox to
debug your javascript and get it to send the proper information.

Once you have the javascript working, start adding code to your PHP file
to do what you need.

Also, think about your code. What do you actually need? For instance,
is the IP address really important? If not, leave it out. You can
always add code later when you get it working.

Also - normally for a PHP development system (you DO have a development
system separate from your production system, right), I normally
recommend your php.ini file contains:

error_reporting = E_ALL
display_errors = On

However, this doesn't help when you're using AJAX because errors in
handling an AJAX request aren't displayed. So for this reason I also
recommend you have

log_errors = On
error_log = (full path to a file here)

BTW - it's easy to change the wrong php.ini file. To find the one being
used, just create a file with only the following line:

<?php phpinfo(); ?>

Upload it to the root directory of your web server and load it in your
browser. One of the things it will show is the php.ini file being used.

As for an alternative (and easier) implementation - just put all of your
input fields in a form and POST it to the server. No javascript
required on the client side (unless you wish to validate data before it
is sent).

Now on the server side, your PHP gets all of the data from the $_POST
array and builds a tab-delimited string and writes the string to a file
(an even better way, IMHO, would be to build an array of parameters and
use fputcsv() to write as a .csv file). Much more straightforward and
easier to implement.

But whichever way you go, I can't stress enough - validate EVERY piece
of information coming from the client. This means data type and value
for each item, to ensure it is good. Never trust anything from the client.

I know this is kinda long - but I hope it helps some.

[Lew Pitcher]

On Saturday February 7 2015 20:29, in comp.lang.php, "F. George McDuffee"

<gmcd...@mcduffee-associates.us> wrote:

> Thanks to everyone who is responding.

You're welcome.

[snip]

> Don't want to invent anything, just use $_POST or $_GET to
> communicate with PHP.

To me, the best choice would be to have the Javascript POST the data, and
the PHP to read it from the appropriate $_POST variable.

Reasons: If the Javascript uses GET, it will have to concatenate the
variable name and the data to the URL before performing the GET. This has a
couple of consequences:
1) you must take extra steps in the Javascript to create the proper URL
before you open the PHP page
2) your data is not secure, as it is now plaintext, included as part of the
request URL and can be intercepted, read, and/or forged

If the Javascript uses POST, then the data does not have to be urlencoded or
concatenated to the URL before the Javascript open() call, and the data is
not exposed as part of the URL, and is now less susceptable to forgery.
However, the Javascript must write the data as part of the document it is
posting, using the appropriate transfer semantics (characterset, type,
name, content).

In both cases, your PHP has to know where to look for the data. It must use
$_GET[] if you had the Javascript open the page with the GET mode, or use
the $_POST[] if you had the Javascript open the page with the POST mode.

[snip]

> How/why did this get so complicated???????????????

Using Javascript to transfer data is more complicated than using html
webforms, that's for certain.

[Denis McMahon]

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, denismf...@gmail.com

[Christoph M. Becker]

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

[Thomas 'PointedEars' Lahn]

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.

[Denis McMahon]

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, denismf...@gmail.com

[Christoph M. Becker]

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

[Thomas 'PointedEars' Lahn]

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.

[Christoph M. Becker]

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

[Thomas 'PointedEars' Lahn]

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'] */

[Christoph M. Becker]

Denis McMahon wrote:

> 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.

I'm mostly basing my statement on RFC 7231, not on various documents.

Regarding my statement that it would not make much sense to submit data
of a search form via a POST request, Thomas 'PointedEars' Lahn has
already made some constructive critism elsewhere in this thread, and
shown that this statement is wrong in the *general* case.

> 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.

However, submitting data that are going to be stored on the server
(appended to a file) with a GET request, would obviously be a violation
of RFC 7231:

| Of the request methods defined by this specification, the GET, HEAD,
| OPTIONS, and TRACE methods are defined to be safe.

| Request methods are considered "safe" if their defined semantics are
| essentially read-only; [...]

| A request method is considered "idempotent" if the intended effect on
| the server of multiple identical requests with that method is the
| same as the effect for a single such request. Of the request methods
| defined by this specification, PUT, DELETE, and safe request methods
| are idempotent.

> I am sure
> however that the OP will consider your unsolicited opinion on the matter
> with whatever gravity[1] he feels it deserves.
>

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

I presume that the OP won't fall prey to your miserable appeal to
emotion, but rather is open to reasoning based on facts.

--
Christoph M. Becker

[Thomas 'PointedEars' Lahn]

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/>

[Christoph M. Becker]

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

[F. George McDuffee]

=======================

NB: I use 16 point font in my ng reader because of a vision
problem, and this may cause "funky" line breaks in the code
snippits.

Thanks to everyone for their helpful comments and
suggestions!

We seem to be making asymptotic progress to a solution to
my undoubtedly stupid problem.

I agree that the POST function is the most appropriate.
There is no need to cache the url or bookmark it.

My problem is I can't get the flaming POST function/command
to work no matter what I try.

the visitor counter works fine
<snip>
<span class="auto-style35">You are visitor # <script
src="http://mcduffee-associates.us/PHP/hitctr/counter.php?page=dummy"></script>
</span></td>
</snip>
and MDItab.php [for Major Depression Inventory + tab
delimited] to append the data to a file is located is
located in the same directory.

Please show me *EXACTLY* what the client side POST should
look like to send window.upstring which is the concatenated
tab delimited data string to MDItab.php *AND*

*EXACTLY* what the function in MDItab.php should be to
receive the data string and assign it to a variable.

My last effort was:

<?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]

{{{{Q: should MDIstring in sq brackets be window.upstring?
I tried this and no workee}}}}

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

</snip>

If I can get the data across, I can take it from there.

This is where my problem is. No combination or permutation
of the examples on the web or in several "dummy's guides"
has worked. I need something more than a black box with the
notation, "here the magic happens."

also tried this -- NO WORKEE
<snip>

//
// directly writes to file.

$handle =
fopen('http://www.mcduffee-associates.us/post/mdi/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 ] )

intval fwrite( resource $handle, string $window.upload )

// bool fclose ( resource $handle )

boll fclose( resource $handle )
//
</snip>

Unka' George

[Matthew Carter]

Don't fopen() an URL, use the filesystem's file path.

For your javascript, get firefox + firebug for a much easier time
debugging what is going on (or an equivalent such as Chromium's built in
inspector), as you can enter a javascript statement at a time in the REPL.

--
Matthew Carter (m...@ahungry.com)
http://ahungry.com

[F. George McDuffee]

On Sun, 08 Feb 2015 21:55:40 -0500, Matthew Carter
<m...@ahungry.com> wrote:

>For your javascript, get firefox + firebug for a much easier time
>debugging what is going on (or an equivalent such as Chromium's built in
>inspector), as you can enter a javascript statement at a time in the REPL.

javascript + HTML is working fine on both Firefox and
Exploder (albeit page was far harder to create than with
Front Page, which if this was still running on the server I
would have had this project done in a few hours including
the data up/download).

I have a version of the php program [not posted] that works
in that it creates/opens a text file on the server and
decodes/appends dummy data strings that I manually load
in-line to a string array and then into the write string
variable, so it should work if I can get the flaming POST
interface operating.

Some graphics still need to be uploaded to be displayed on
the server version but page is fully functional [try it out]
except........ for my inability to one way or another
jam/ram/cram <window.upstring> into MDItab.php on the
server. If this was on the shop floor, I would be reaching
for a bigger hammer or possibly a Rotorooter.

At this point I am not looking for an elegant solution, JUST
A KLUGE TO CRAM THE DATA STRING INTO THE PHP PROGRAM TO
WRITE TO A FILE ON THE SERVER.

Firefox is my main browser and I have firebug installed, but
for WYSIWYG page layout I find that M/S Expression Web 4 is
what I use most of the time. [FWIW: Bought it just before
M/S released it for free...] I find this to be a good code
editor for both JS/HTML and php, and is a good IDE for me.

Now if I can just get that web survey to talk to the
server!!!!!!!!!!!!!!!!!!!

[Denis McMahon]

On Mon, 09 Feb 2015 00:40:37 +0100, Christoph M. Becker wrote:

> I'm mostly basing my statement on RFC 7231, not on various documents.

> However, submitting data that are going to be stored on the server
> (appended to a file) with a GET request, would obviously be a violation
> of RFC 7231:

As far as I can tell, RFC 7231 specifies a data transfer protocol. It's
outside the remit or concern of such a protocol what happens to any data
it carries after it has been transferred.

That you can't spot this flaw in the document you're quoting speaks
volumes for your knowledge of the internet.

--
Denis McMahon, denismf...@gmail.com

[Christoph M. Becker]

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

[Christoph M. Becker]

F. George McDuffee wrote:

> Please show me *EXACTLY* what the client side POST should
> look like to send window.upstring which is the concatenated
> tab delimited data string to MDItab.php *AND*
>
> *EXACTLY* what the function in MDItab.php should be to
> receive the data string and assign it to a variable.

You shouldn't expect ready to use solutions from this newsgroup, but
rather some helpful (and sometimes maybe not so helpful) hints. :)

The following code is hardly analyzable, due to line breaks inserted by
newsreaders. You should consider reformatting any code to not exceed,
say, 72 characters per line, before posting it to Usenet.

> <?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]

Here the trailing semicolon is missing. It doesn't have to be written
on the same line, though, but that's customary and easier to read. The
missing semicolon causes the PHP engine to abort script processing with
a fatal error. I suggest you enable error_reporting and have a look in
the error log.[1]

> if ( ! isset($_GET['MDIstring']) ) // quotes?

Yes. You should always quote strings (opposed to constants).

[1] <http://php.net/manual/en/errorfunc.configuration.php>

--
Christoph M. Becker

[Lew Pitcher]

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

Using the code you gave us, your Javascript should look something like...

function SendString( )
{
xmlhttp.open("POST","MDItest.php",true);

// window.upstring contains "MDIstring=<your tab delimited data>"
xmlhttp.send(window.upstring);
}

and your PHP should look like...

<?php

if (isset($_POST['MDIstring']))
{
// append received MDIstring to file of saved MDIstrings
$handle = fopen($FILEPATH,'a');
fwrite($handle,$_POST['MDIstring']);
fclose($handle);
}

?>

The client javascript POSTs the survey values; the server PHP script
retrieves the survey values from the POST variables.

Enhancements (like urlencoding, etc) are left to you.

Good luck

[Christoph M. Becker]

Denis McMahon wrote:

> On Mon, 09 Feb 2015 00:40:37 +0100, Christoph M. Becker wrote:
>
>> I'm mostly basing my statement on RFC 7231, not on various documents.
>
>> However, submitting data that are going to be stored on the server
>> (appended to a file) with a GET request, would obviously be a violation
>> of RFC 7231:
>
> As far as I can tell, RFC 7231 specifies a data transfer protocol. It's
> outside the remit or concern of such a protocol what happens to any data
> it carries after it has been transferred.

At least that's not the case for HTTP, which specifies, for instance,
the semantics of (client-side) caching. If that was not so, the *WWW*
would be an even greater mess as it is.

Consider the given survey form would be submitted via a GET request.
Anybody requesting the very URI again, would cause the same record to be
appended to the file another time. This could even be the original
submitter, pressing F5 inadvertently -- a former POST submission would
have triggered a warning in any contemporary browser.[1] Furthermore
the original submitter might bookmark the current URI after form
submission -- consider what happens when she accesses the bookmark next
time.[2] Consider what happens if this URI is shared on a social
network, for instance.

> That you can't spot this flaw in the document you're quoting speaks
> volumes for your knowledge of the internet.

Ex falso quodlibet.

[1] I am aware that multiple submission of the same data are still
possible with a POST request without warning, though.
[2] I am also aware that there are workarounds to prevent storing the
data twice, but these are unreliable and merely try to work around the
HTTP specification.

--
Christoph M. Becker