in reply to Re: the search string and me
in thread the search string and me
Thanks for the comments,
___ /\__\ "What is the world coming to?" \/__/ www.wolispace.com
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: the search string and me
by jonadab (Parson) on Sep 15, 2003 at 15:41 UTC | |
can you give me a link to your "See my obfuscated version above.." Yes, here. That's been deliberatly obfuscated, but in a nutshell I just take the raw input from the CGI query, split on ampersands, do a foreach loop over the result, split on equal signs, feed the resulting list through a map that unmangles the rest of the characters (including any encoded ampersands and equal signs, incidentally), and the result will be a key/value pair that can be stored in the input hash. Splitting first, *then* unmangling the result, has the benefit of removing from consideration any complications that might otherwise result from getting mixed up about what is and what is not a demangled ampersand or equal sign. It's also simple and straightforward (when it hasn't been deliberately obfuscated). This only handles key/value pairs delimited by ampersands, with the equal sign separating the key from the value, but all GET queries and most normal POST input will come to you that way, even if you use a big fat textarea. (I believe my non-obfuscated version also handles the case of an equal sign in the value (though of course there can't be one in the key unless it's encoded) by using the extra optional arg to split; I golfed that out of the obfuscated version. The only circumstances I've encountered thus far where you get something different (apart from cookies, which come in their own environment variable) is with file uploads; in that case you have to parse a custom boundary marker and deal with multiple parts and other stuff, and it does get rather more complex; if you need to do that, I suggest getting a module that does it for you, unless your purpose in rolling your own is to learn how it works. I rolled my own to figure out how it works, but I only ever used it to test that I had it working; since then, I've only used the regular kind of input, not having a need for file uploads. If I need to get files to the server, I ssh in and wget them from the Apache on my workstation, which has the added benefit of being resumable if my dialup connection dies partway through. If at some point in the future I discover a need to parse file uploads and store the file, I'll probably look for a module that does that; my own routine for that is too complex for me to be sure it doesn't have lurking bugs. However, for regular CGI input, I am fairly confident in my implementation; it's very simple, very straightforward. In the form I normally use it, it's a sub in an include file that I require, and it returns a reference to a hash containing all the input, (with all of the keys and values marked as tainted, in case I should forget myself and try to do anything insecure with them). The calling script usually dereferences and assigns the result to a global hash called %input
| [reply] [d/l] |
by wolis (Scribe) on Sep 16, 2003 at 01:02 UTC | |
The bit Im unclear about is if a form is submited with Are ALL instances of & and = in a form post (or get) converted into their 'mapped' character on the way through to the perl code? For some reason I didn't think this was the case <shrug> I have rolled my own file uploader too.. again just to understand how it all works.
| [reply] [d/l] [select] |
by jonadab (Parson) on Sep 16, 2003 at 03:47 UTC | |
<input tupe="text" name="foo" value="bing&bong=bang"> The browser is required to encode the value. If you find one that doesn't, I'd be interested in knowing. Although, I should also note that technically the above is not good HTML; the ampersand should really be given as an entity, which the browser will decode; however, when the browser submits a form, it is always required to encode certain characters (including equal signs and ampersands) in an any of the keys or values using the CGI-style encoding (with the percent sign). And in practice, the unencoded ampersand in the quoted attribute like that will only be a problem if the document is served as XML (in which case, the document won't render at all; the browser will show an error message to the effect that it's invalid); with an HTML content type, all major browsers will handle the above in the intended way.
| [reply] [d/l] [select] |