Suggested Title:


 


Note To Mobile Users:

This page is not mobile-freindly.

This is mainly because Mobile Browsers generally lack the 'Save Page As...' function, which Desktop Browsers usually have.

Instead, when a Mobile Browser Shares a current Web-page to another app, it only sends a URL to that app.

If this page was to use the 'GET' Method, it would submit the document to my CGI-script as part of a rather lengthy URL, and to Share the result with another app would actually work.

But intsead, this page submits the Textarea using the 'POST' Method, which is correct for larger amounts of data, but which will cause the next app only to receive a blank URL, which hints of no document. The 'POST' Method sends Form Data to the server through a separate channel.

I happen to know of one solution, which will work under Android:

This combination will actually Save the page that the browser has loaded, and not a URL.

The page would both need to be composed within Dolphin Browser first, and after the Submit Button was tapped, Dolphin could then be told, actually to Save the page to a File on the Mobile Device (that will be a PDF).


I happen to know of another solution, which will work under Android:


 

The 'GET' Method is a traditional way by which a Web-browser requests data from the Web-server, in which effectively, the browser attempts to open a URL, which begins by naming a CGI-script, after which a question-mark follows, followed by Name-Value Pairs connected with equal-signs, that are all encoded using standards for representing even special characters, but just using ASCII. Spaces for example are not allowed, but hexadecimal-ASCII equivalents are allowed that begin with a percent-sign... This means that Form Data is organized by the browser and converted into Name-Value Pairs, that are thereby appended to the URL and become part of it. The CGI-script itself is a procedural computer program that runs on the server, and that is expected to output or 'print' an HTML document back to the browser, which the URL that defined the 'GET Request' identifies retroactively. The Name-Value Pairs act as input to this program.

One drawback in the use of 'GET Requests' is, that making one loads a new Web-page into the browser. One alternative to 'GET' is 'POST', which allows similar CGI-scripts to run on the server, and which also forces a new Web-page to be loaded. But with 'POST', the Name-Value Pairs are sent to the server separately from the URL of the CGI-script.

A different, more-modern alternative to 'GET' and 'POST' is referred to often as 'AJAX', but works by a different logic. 'AJAX' is built around the'XMLHttpRequest()' JavaScript function, again invokes a server-side script, but only with the result that formatted data output by the server-script is received by the JavaScript of a page (on the browser), without requiring that the page be reloaded. This can allow parts of a page to be updated.

I tend to look at the use of 'GET' URLs, as though they had permanent meaning, as jingoistic. The response of the server-script cannot be guaranteed consistent, to any one Request, and larger amounts of data cannot be represented in this way, because there is also some ultimate limit to the length of a URL. One would not write a novel and append its contents to one URL. Further, the consistency that is obtained with 'GET' URLs, is sometimes only achieved because an actual volume of data remains stored on the server, and because the 'GET Request' contains an identification code, by which that volume of data can be selected - by the server-script.

Dirk