base64 / mime prc table

[Brian K. White]

Fairlight wrote:
> On Tue, Nov 09, 2004 at 07:20:04PM -0500, Brian K. White, the
> prominent pundit, witicized:
>> Mark had said he though I had written a prc table to do base64, and
>> I almost
>
> Maybe we were talking at cross-purposes at the time.  It happens.
>
>> is working great and it has one advantage in that it's a single
>> black box that both fp processes and cgi & cron scripts use to
>> code/decode stuff for each other and I can make any kind of change I
>> want in that script and not break anything else as long as the
>> script still decodes what it encodes)
>
> Of course, it's a single fault point if you do break it, which then
> breaks
> all things dependant on it.  :)
>
>> http://www.aljex.com/bkw/filepro/#urlenc
>
> :"$&+,/;=?@ <>#%{}|^~[]`'"{chr("92"){chr("34") co urlenc_ic:urlenc_oc
> = "%" { base(asc(urlenc_ic),"10","16"):
>
> I have a few problems with that as written.
>
> You don't want to encode the @ character at all--that's a valid part
> of the user:pass at host syntax in URLs, and should be left unmolested.
> The browsers generally take care of themselves, but if you insist on
> replacing it, you should make sure you've done a state check for
> passing the first / that indicates the beginning of $PATH_INFO and/or
> $QUERY_STRING, or that you've already passed one @ prior ot that (in
> which case, someone feeding it a bad URL gets what they deserve,
> which is a failed connection).
>
> Likewise, you're also nuking valid & and ? characters that are a
> valid part
> of URLs of the GET style.  You need to track having passed the
> appropriate place in the URL for ?, similar to the @ example.  The &
> however, should -never- be encoded unless it comes -before- the end
> of the hostname
> section, and even then it's illegal and should be removed.  There's
> just
> no reason to encode one.  I think you may have been lumping in HTML
> entity encoding and URL encoding in the same cargo container when you
> wrote this.
>
> The other problem is that it's not robust enough to check for
> pre-encoded characters.  You could get %7E in a URL and need to
> filter the rest, but you've not checked to make sure that your % is
> not followed by a valid hex code, therefore you'd be re-encoding it
> as %377E, which would -not- give
> you what you wanted, as they only decode one layer deep when
> urldecoded
> by any piece of software I've seen.  Some people will give URL's that
> are partially encoded--you'll have an encoded tilde as above, but
> other things need changing.  You should really check for a valid hex
> value read-ahead
> after any %, just to make sure you don't do something like the above.
> It would extend the logic by a few lines, but not bloat it hugely or
> unmanageably.
>
> No offense intended.  It's elegant in its simplicity, but if someone
> fed it half-encoded URL's, it could lead to error as written.  It
> could easily be made more robust though, with those few changes.
>
> mark->

Whoa hold up there Captain Incredulous.

Yes it encodes special url characters, that's the POINT.
If an item of data, one field, in the query string will have any of those 
characters in it, they need to be encoded, else they will be interpreted and 
acted upon by the browser.

This is just an encoder, if you are so stupid as to encode a whole url with 
it instead of just the parts that need it, that's your learning experience, 
I already know where to use a screwdriver and where not to. :)

There are no half-encoded urls, there are no already encoded %, if there is 
a % in the data, then it needs to be encoded, there is nothing in the entire 
diatribe above that has a spec of applicability, you started off in a wrong 
direction and went a mile in it instead of a few steps is all. Next time I 
suggest starting with a question instead of a mountain of wrong answers.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani