base64 / mime prc table

Brian K. White brian at aljex.com
Thu Nov 11 00:02:49 PST 2004


Fairlight wrote:
> In the relative spacial/temporal region of
> Wed, Nov 10, 2004 at 11:23:21AM -0500, Brian K. White achieved the
> spontaneous generation of the following:
> [ah, the fine art of trimming]
>> Whoa hold up there Captain Incredulous.
>
> That's Captain Incredulous SIR.  :)
>
>> 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. :)
>
> Yes, but while you and I know this, I can just see people tossing wole
> URL's at it.  Don't laugh, Brian--I've seen less intelligent moves.
> I'm
> just saying that your idea could be expanded upon to be robust enough
> to survive even -that- kind of move.  The algorithmic logic isn't
> hard, it's just a minor annoyance.
>
>> 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.
>
> They're right answers for making it really robust -if- you go from the
> assumption that people often don't know what they're
> doing--especially when they're doing it for the first time.  Someone
> getting your table probably
> has never needed to do it before, or they'd have written their own.
> Those are the ones that are a danger to themselves, and the ones for
> which you
> have to bulletproof everything.
>
> I'd wager that at some point, someone will download your table and
> toss an entire URL at it, and may not get what they really wanted.
> That's almost a sure bet.  So the questions are...do you care if they
> have a bad experience the first time out, and do you feel like
> explaining their mistke to them?

I could care less. I doubt more than three people will ever download it.
I think it's main value (other than my own copy that I actually use) is just 
to look at the line in the middle and take away the idea.
You could type it in faster than download & install it. The binaries are 
somewhat useful maybe.

It's a mistake to *try* to second guess the users intentions in this 
respect.

This isn't a "program" it's a "routine". It does a specific task and nothing 
else and that's as it _should_ be. A larger more complex program that needs 
to parse or construct whole urls might include this routine to encode the 
bits that it wants encoded, but this routine is not that larger program.

I want the container to contain _whatever_ data I put in it, including 
potentially data that is indistinguishable from the container.
How do you parse a url and know for a fact that you are doing it right and 
that I didn't want to submit a whole valid url as part of the query string 
within a url? Don't say "change the cgi so that you submit the info to 
recreate a url not a actual url" maybe the cgi is a database of urls or a 
url syntax checker?

The day my screwdriver starts second guessing which way I want to turn it, 
or how hard, is the day I take an acetylene torch to said screwdriver.

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



More information about the Filepro-list mailing list