SPUG: Re: perl2exe perl-cgi file size problem

William Julien moonbeam at catmanor.com
Thu May 2 23:47:00 CDT 2002


>
>On Thu, May 02, 2002 at 07:11:40PM -0700, William Julien wrote:
>> >...
>> >> Modern browsers use ';' instead of '&' to separate parameters in the URL.
>> >> The [deleted] code sample would not handle that, so it may well fail to
>> >> just read text from a simple form input.
>> >>
>> >> I'd strongly suggest using CGI.pm instead of any hand-rolled solution.
>> 
>> Per rfc, the "&" is the delimintor. The examples given on the web pages
>> provied were handling the case where you have "&;". eg:
>
>One of the examples on given on one of the pages says:
>
>  'it doesn't handle the recommend ";" separator instead of "&"'
>
>(http://www.perlmonks.org/index.pl?node_id=28499)
>
>> 
>> The only time when this is an issue is when the broser issues a post or
>> get with a set of complex multipart mixed boundries. This is application
>> dependant, and under the control of the server code which designed to
>> work with multipart/mixed mime headers, and browser object parameters. No
>> browser that I know of replaces "&" for ";" on the get or post delimitor.
>
>Perhaps I shouldn't have said browsers. However, if you attempt embedding
>URI's with appended query strings into xhtml documents, you will soon
>see the advantage of using ';' as the separator instead of '&' (which
>becomes '&' in any xml, including xhtml).
>
>> See...
>> 
>> http://www.perl.org/CGI_MetaFAQ.html
>> http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1808.html
>
>Old info... see:
>
>http://www.faqs.org/rfcs/rfc2396.html 
>(updates rfc1808)
>
>I still stand by CGI.pm, which Does the Right Thing! ;-)

Thanks for the reference. I took a look at the RFC. I must admit, I have
not kept up with the latest xhtml extensions. It makes sense that this
"superset" of operations would make use of the ;param specification
of rfc1808. A handy way to handle multipart content. So far, I have
generally ignored the xhtml specifications. They provide a capability
I don't really need. The rfc2396 may update rfc1808, but who cares. :-)

Well, maybe by the time I retire, rfc2396 will become relevant. But
it is "a good thing" (tm) that CGI.pm is prepared to support the xhtml
extentions. Kudos to the CGI.pm programmers.

I tend not to use CGI.pm, simply because I like to write my own code. I
realise this is pendantic, but I feel it gives me more control over
the result. I check all my pages with an nsgml syntax checker. Something
I'm sure the CGI.pm authors have also done. But I like having greater
control over its format, syntax and structure.

---
   William Julien           _,'|            _.-''``-...___..--';
moonbeam at catmanor.com      /, \'.      _..-' ,      ,--...--'''
 vi is my shepherd;       < \   .`--'''      `     /| 
 i shall not font.         `-,;'              ;   ; ;  
                     __...--''     __...--_..'  .;.'  
                    (,__....----'''      (,..--''     
perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
perl -e '( $ ,, $ ")=("a".."z")[0,-1]; print "sh", $ ","m\n";;";;"'

>
>-C.
>

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     POST TO: spug-list at pm.org       PROBLEMS: owner-spug-list at pm.org
      Subscriptions; Email to majordomo at pm.org:  ACTION  LIST  EMAIL
  Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
 For daily traffic, use spug-list for LIST ;  for weekly, spug-list-digest
     Seattle Perl Users Group (SPUG) Home Page: http://seattleperl.org




More information about the spug-list mailing list