Re: CGI and euc
- Posted by useless_ Jan 14, 2013
- 2378 views
You know, i am not going to keep fixing the creole paragraphing and attributions below.......................
According to me and O'Reilly, the CGI script is perfectly within it's limits to make a complete HTTP header to send to the httpd. Technically, HTTP/1.0 is obsolete, and yet people still use it. And while i am mentioning O'Reilly, here's a quote from one of his books:
print "$server_protocol 200 OK", "\n"; print "Server: $server_software", "\n"; print "Content-type: text/plain", "\n\n"; print "OK, Here I go. I am going to count from 1 to 50!", "\n";
That seems strange; one of the previous posts implied that actually was the cause of the issue. I've never seen nor tested it myself.
This statement from the same chapter may imply it might not be supported by modern servers-
How does the server know if the CGI program has output a partial or a complete HTTP header without "looking" at it? It depends on which server you use. On the NCSA and CERN servers, programs that output complete headers must start with the "nph-" prefix (e.g., nph-test.pl), which stands for Non-Parsed Header.
Note the lack of \r at the end of header lines or between the header and the body. This is why i say Euphoria should be adaptive or smart when parsing headers, and not enforce the rules du jour. Basically, whatever the first line ends with, that's what you are going to get as a line/header terminator, and i don't care if it's "right" or not, it's what is.
I have yet to witness a server not translate \n to \r\n when going from CGI to HTTP, as required by the HTTP spec. \n as a linebreak actually seems to be legal in CGI, yet I've seen no case where it ever makes it to the browser that way. If you know one that does, by all means, post it.
AGAIN, i am not logging all the various headers formats i have run across. My goal was to get the webpage, not document how it was sent.
There should be a space after the semicolon in headers:
Content-Type: text/javascript
Any number of spaces, even, from RFC2616: "The field value MAY be preceded by any amount of LWS, though a single SP is preferred.". Use only one *to make CoBaJo happy.
I didn't say that, the spec did. You quoted it yourself- "a single SP is preferred".
To quote the same RFC: "Applications ought to follow "common form", where one is known or indicated, when generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common forms."
Right, "preferred" and "common form", so do not hardcode Eu to look for only one space and crash if zero or two are found.
Strictly speaking, LWS also includes linebreaks, which would complicate parsing headers.. However, again, I've never witnessed any server ignore the recommendation to "follow a common form". CGI headers in an uncommon form are corrected before being transmitted.
Unless the header is built by the CGI app, then it is sent as the httpd recieves it.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">HTML Transitional has been obsolete for quite a number of years; Use HTML5- <!DOCTYPE html>
This site uses Transitional, so does my site. If the page is compliant to what's stated, and you simply change that header, your page is likely not compliant to HTML5 and will display wrong.
"Transitional" was for transitioning from HTML 3 to HTML 4; we're now on HTML5. Transitional is fine, if you wrote the page in 1999. Bugmagnet's code, presumably, was made in 2013, and thus should be using HTML5.
As an aside, I'm not sure why openeuphoria.org is using Transitional; at the very least, it should have been using Strict; it was probably copy-paste from an out-of-date tutorial. Theres no mandate to update old pages to HTML5, but note that doing so would not break anything.
<script src="http://localhost:8088/cgi/suck.exe?argument=nothing particular" type="text/javascript"></script>Spaces aren't valid in URLs; encode them as + or %20.
I have links such as
<a href="canoe pontoons.html">and they work fine. The browser handles it. It's not illegal to have spaces until the space is actually sent to the server to get a page or post data.
The browser is required to handle syntax errors; that doesn't make them valid. [/quote]
[/quote]
[/quote]
[/quote]
I wasn't discussing browsers, i was discussing a Eu CGI app sending urls in plain un-escaped text to anything. My Eu code can read plain text in webpages and decide to follow or not, escape or not, and my choices of browsers behave well also. I am not changing anything to suit you.
Error Line 11, Column 100: Bad value http://localhost:8088/cgi/suck.exe?argument=nothing particular for attribute src on element script: Whitespace in query component. Use %20 in place of spaces.
…088/cgi/suck.exe?argument=nothing particular" type="text/javascript"></script>
Syntax of IRI reference:
Any URL. For example: /hello, #canvas, or http://example.org/. Characters should be represented in NFC and spaces should be escaped as %20.
As general good programmng style, you should encode just prior to sending, as a single point in the program, for everything (not in the page body) being sent, else you could have a program flow bug where the url gets encoded twice. I've seen it happen.
In the case of writing HTML, this point would be when the data is output to the browser. The browser itself won't re-encode the URL unless it contains invalid characters already. [/quote] [/quote]
[/quote]
[/quote]
[/quote]
I thought we were talking about Euphoria CGI and Euphoria page fetching, i don't care what a browser will or won't or when do. Your Eu code should do whatever, then call url_encode() then call get_url(). Or whatever they are called now.
And by the way, i also will object to http.e transparently following redirects, perhaps i don't want to goto the new url, the programmer should see the redirect and decide yes/no to send the new url to http.e for a second fetch.
I noted this as well-
There should probably be a parameter "redirect_limit" or similar (defaulting to, say, 10) to specify how many it should follow (which, if set to 0, would either keep the current behavior or just error out). It may also be wise to hardcode an absolute maximum for that value as well.
[/quote]
It should default to NOT following a redirect. A server responce should be returned to the programmer for due consideration.
useless
