Home > Archive > PERL Miscellaneous > July 2004 > CGI parameter separation characters
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
CGI parameter separation characters
|
|
| Seungbeom Kim 2004-07-28, 9:00 pm |
| Bob Walton wrote:
> The broken crappy code you posted doesn't even
> recognize that ; is a valid parameter separation character, in addition
> to & , for example.
This might be out of topic, but I'm curious which document specifies
that ';' is a valid parameter separation character in addition to '&'.
I couldn't find it in the CGI/1.1, CGI/1.2 specifications.
--
Seungbeom Kim
| |
| Gunnar Hjalmarsson 2004-07-28, 9:00 pm |
| Seungbeom Kim wrote:
> Bob Walton wrote:
>
> This might be out of topic, but I'm curious which document
> specifies that ';' is a valid parameter separation character in
> addition to '&'. I couldn't find it in the CGI/1.1, CGI/1.2
> specifications.
It's not. But ';' is often used in query-strings.
Now, an URL with a query-string results in a GET request, while the
original subject of this thread made clear that the OP asked about
POST requests. Accordingly, the code posted by the OP is not "broken"
because of only recognizing '&' as a param separator. It's not
"broken" for any other reason either, but it probably does what it's
supposed to do just fine.
However, in this group people often post comments like that, blunting
the intellect. They do it in order to let you know that you are a
moron if you don't use CGI.pm (or possibly some other module/library)
for parsing CGI data. To make their point, they typically claim that
code like the one the OP posted is "broken" since it doesn't handle
various things that it was never supposed to handle. Often they also
mention irrelevant security aspects. An example of the latter is that
Bob mentioned denial of service attacks, and then he posted code that
is just as exposed to such attacks as the code the OP had posted...
Consequently, beware of this group if you want to *learn* something
about CGI, other than 1) it's off topic here and 2) you should use CGI.pm.
Now, there are good, perfectly valid reasons for using CGI.pm, just as
there are good reasons for using other modules when feasible. It's a
shame IMO that people advocating the use of the module can't stick to
those reasons.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Jürgen Exner 2004-07-28, 9:00 pm |
| Gunnar Hjalmarsson wrote:
[...]
> Consequently, beware of this group if you want to *learn* something
> about CGI, other than 1) it's off topic here and 2) [...].
AMEN to that!
jue
| |
| Bob Walton 2004-07-28, 9:00 pm |
| Seungbeom Kim wrote:
> Bob Walton wrote:
>
>
>
> This might be out of topic, but I'm curious which document specifies
> that ';' is a valid parameter separation character in addition to '&'. I
> couldn't find it in the CGI/1.1, CGI/1.2 specifications.
>
Well, I don't know what document it is specified in, but there is a
discussion about it in the docs for the CGI module:
perldoc CGI
in the "PRAGMAS" section, under the -newstyle_urls and -oldstyle_urls
pragmas, and stuff in the CGI.pm code itself. There are lots of web
references to the & pair separator being deprecated and replaced with ;
as the separator. Maybe someone in a CGI-oriented newsgroup would know
better where this appears in the standards?
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
| |
| Bob Walton 2004-07-28, 9:00 pm |
| Gunnar Hjalmarsson wrote:
> Seungbeom Kim wrote:
>
>
>
> It's not. But ';' is often used in query-strings.
Hmmmm...check out:
perldoc CGI
in the PRAGMAS section under the -newstyle_urls and -oldstyle_urls pragmas.
....
> Bob mentioned denial of service attacks, and then he posted code that
> is just as exposed to such attacks as the code the OP had posted...
True, but easily fixed with the addition of
$CGI::POST_MAX=100000;
or so at the beginning of the script, as one can note in
perldoc CGI
in the "Avoiding Denial of Service Attacks" section. My code was
intended to illustrate the ease of using the CGI module, but would have
been better with that addition.
> Consequently, beware of this group if you want to *learn* something
> about CGI, other than 1) it's off topic here and 2) you should use
> CGI.pm.
Agreed. Point well made.
....
--
Bob Walton
Email: http://bwalton.com/cgi-bin/emailbob.pl
| |
| Gunnar Hjalmarsson 2004-07-28, 9:00 pm |
| Bob Walton wrote:
> Gunnar Hjalmarsson wrote:
>
> True, but easily fixed with the addition of
>
> $CGI::POST_MAX=100000;
>
> or so at the beginning of the script,
Yes, or without CGI.pm by simply doing something like this:
unless ( $ENV{CONTENT_LENGTH} > 100000 ) {
# read STDIN and parse the data
} else {
# do something else
}
But you stripped the context in which I made that comment. You brought
up the risk for DoS attacks as a reason for using CGI.pm (which it
isn't), followed by code that included "use CGI" etc. but without any
limitation of POSTed data. By doing so, you sent the incorrect message
to the readers of this group that if they only use CGI.pm, they are
protected against DoS attacks. (Joe S. made a similar incorrect
comment in comp.lang.perl in reply to the same OP.)
That's nothing but desinformation, and since we are talking about a
significant *security* issue that people are made believe is
automatically taken care of by CGI.pm, it's the worst kind of
desinformation!
Bob, Joe, and (previously) several other regulars: Why do you
repeatedly do that? Why??
>
> Agreed. Point well made.
Do you really think so? I doubt it was, since I failed to include that
you should not only expect to not learn CGI, but in addition to that
you should be aware of *incorrect* statements about CGI being made
frequently, also by knowledgable regulars. :(
Many posters here seem not to want to discuss Perl programs that are
to be used in a CGI context. That's fine. But then they'd better keep
their mouths shut rather than posting desinformation.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
| |
| Sherm Pendley 2004-07-28, 9:00 pm |
| Bob Walton wrote:
> as the separator. Maybe someone in a CGI-oriented newsgroup would know
> better where this appears in the standards?
I think that part of the problem is that there is no CGI "standard" as
such. The closest thing we have to one is NCSA's original documentation:
<http://hoohoo.ncsa.uiuc.edu/cgi/>
There appears to have been an attempt made to organize and submit an RFC
to the IETF, thus creating a formal standard, but that attempt appears
to have died on the vine:
<http://cgi-spec.golux.com/>
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
| |
| Alan J. Flavell 2004-07-28, 9:00 pm |
|
I know this is the wrong place; but as the topic has come up, I think
this is worth saying, if you'll excuse me:
On Sun, 25 Jul 2004, Sherm Pendley wrote:
> I think that part of the problem is that there is no CGI "standard" as
> such. The closest thing we have to one is NCSA's original documentation:
>
> <http://hoohoo.ncsa.uiuc.edu/cgi/>
It's a respectable point of view, don't get me wrong, but those old
NCSA specs are a bit chatty and vague...
> There appears to have been an attempt made to organize and submit an RFC
> to the IETF, thus creating a formal standard, but that attempt appears
> to have died on the vine:
>
> <http://cgi-spec.golux.com/>
It has stopped proceeding to a more-formal stage, fair comment; but
the CGI/1.1 draft had as its goal:
Goal: Clearly and concisely codify "current practice" of CGI/1.1
usage on the Web as of 2000.
and I'd say it has achieved that goal well. I would definitely
recommend consulting it as a reliable source of "current practice",
irrespective of its position on the IETF's greasy pole. IMHO.
But the issue of using semi-colon as the alternative delimeter in
composed GET URLs is codified in the *HTML* specifications, starting
with RFC1866/HTML2.0. The CGI specification does not go into detail
about the format of the QUERY_STRING, but cites other relevant
specifications for it. With POST, on the other hand, the problem
simply doesn't arise for which the semi-colon is the suggested
solution, and so no solution is really needed.
I'd better shut up now.
| |
| Joe Schaefer 2004-07-28, 9:00 pm |
| "Alan J. Flavell" <flavell@ph.gla.ac.uk> writes:
[...]
> With POST, on the other hand, the problem
> simply doesn't arise for which the semi-colon is the suggested
> solution, and so no solution is really needed.
FYI: the semicolon is the default separator for the (deprecated)
urlencoded-post method described in the XForms 1.0 spec.
http://www.w3.org/TR/xforms/slice11...alize-urlencode
Earlier drafts mandated ';' as the separator, however the spec
authors eventually recognized that decision was problematic for
POST, so they allowed the separator to be configurable by the form
author to either ';' or '&'.
Allowing ';' as the separator is a good idea anyways, since
it lets future XForms authors make use of your script without
having to fuss over the choice of separator.
--
Joe Schaefer
| |
| Seungbeom Kim 2004-07-28, 9:00 pm |
| Alan J. Flavell wrote:
> But the issue of using semi-colon as the alternative delimeter in
> composed GET URLs is codified in the *HTML* specifications, starting
> with RFC1866/HTML2.0. The CGI specification does not go into detail
> about the format of the QUERY_STRING, but cites other relevant
> specifications for it. With POST, on the other hand, the problem
> simply doesn't arise for which the semi-colon is the suggested
> solution, and so no solution is really needed.
The HTML 4.01 Specification still mentions only '&' as the separation
character: http://www.w3.org/TR/html4/interact...tml#h-17.13.4.1
Sorry for continuing this topic here, but many people have responded and
shown interest about this, so I ask for your understanding.
--
Seungbeom Kim
| |
|
|
|
|
|