> From: "Dave Hoover" <[EMAIL PROTECTED]> > Date: Sat, 8 Jun 2002 06:38:45 -0500 > > Eugene wrote: > > En op 08 juni 2002 sprak Dave Hoover: > > > Lars brought up the idea of using syntax like %00 to be > > > interpreted as binary zero. This isn't done automatically, but > > > by checking off a checkbox on the submit page that would run > > > CGI::unescape on the code prior to any processing, I think it > > > could work. What does everyone think about this?
> > That is one option. Alternatively, you could perhaps use <INPUT > > TYPE="file"> to upload files. > This has been suggested before and I remember resisting it. I > realize now, though, that my resistance was based on a false > assumption that it would require PGAS to store all of these > solutions as files. I think this could work...does anyone see any > downside to this approach? > After reading Ton's suggestion, perhaps it could be written to a > file for use as an email attachment for the goto referee (and then > immediately rm'd). Some random comments on all this: The limits on what characters are possible, are to a large extent in the browsers used to submit. As far as I can see, PGAS takes the text as presented by the browser and puts it directly into the database. (I'm sure the HTML and/or HTTP standards have words that disallow NULs and CRs without NLs, but whether they must apply to what can be sent from a textarea input, I don't know). My %00 suggestion was actually a way to hack the submission process: the script that you paste into the text widget ends up in a url-encoded string, with most non-alphanumeric characters as %xx, and I found that one way of getting a NUL into PGAS was to fake up a HTTP POST with a %00 in the appropriate spot. There's a rejected 161.23 submission in the post-mortem that shows the result. So that was not actually a suggestion for what to put into the text widget --- I don't actually like %xx as an escape for humans to use, but then for the sort of program text we're talking about here, all the good ways are goint to conflict with Perl's own mechanisms. But how does CGI:unencode react to % characters that are not part of an escape? I'd like most uses of it to pass through unscathed, so that people don't have to put %25 in format strings and the like. (But if there's a checkbox to enable it, the submitter should know to escape their %'s if they check it). As to needing separate files to allow download as files from the post-mortem page, and in emails to the refs: of course it's easier that way, since you can just hand out an URL to the file, or use whatever function to attach a named file to an email in B64, but there's no reason that a CGI script can't output a raw script as application/x-perl-script or whatever, directly from the database (given a unique identifier of course), or that the add-attachment function can't take a Perl string directly. The same goes for the file upload thing --- it's been too long since I read the RFC, so I don't remember the exact form the file contents take in the HTTP request --- but I'm sure it can be captured in a Perl string and stored in the database. Lars Mathiesen (U of Copenhagen CS Dep) <[EMAIL PROTECTED]> (Humour NOT marked)
