Pickwick has asked for the wisdom of the Perl Monks concerning the following question:
Hello all,
I have a web application with it's own little template system, which gets all parameters of a request using the CGI class to build a hash with names and values, which is later in the system used in simple text replacements to put the values under the parameter's names in html templates. The functions used don't know any context, the system is used in three web applications and therefore has to be pretty general to not break anything.
My problem now is that in one context I need to transfer BASE64 encoded data into a template to afterwards can send it back to another target on user's request. The encoded data can contain the +-character, which seems to be converted to a space directly in the CGI-class using CGI::Util::unescape and of course invalidates my data. This behaviour seems to be hard coded and not data dependent or something like that. My only idea to get around this would be to configure a list of parameter names in the template system where spaces can safely be reconverted to +-characters. This sounds error prone to me, because every new parameter has to be configured as well, something which will surely be forgotten over time.
Do you think of any other way to get around this problem?
Thanks!
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: CGI-class changes + to space for BASE64-data
by moritz (Cardinal) on Dec 01, 2010 at 10:05 UTC | |
by Pickwick (Beadle) on Dec 01, 2010 at 10:53 UTC | |
Re: CGI-class changes + to space for BASE64-data
by JavaFan (Canon) on Dec 01, 2010 at 11:34 UTC | |
Re: CGI-class changes + to space for BASE64-data
by fullermd (Priest) on Dec 01, 2010 at 10:27 UTC | |
by Pickwick (Beadle) on Dec 01, 2010 at 10:56 UTC | |
Re: CGI-class changes + to space for BASE64-data
by ikegami (Patriarch) on Dec 01, 2010 at 16:41 UTC | |
Re: CGI-class changes + to space for BASE64-data
by chrestomanci (Priest) on Dec 01, 2010 at 11:13 UTC | |
by ikegami (Patriarch) on Dec 01, 2010 at 16:49 UTC |