Re: Encoding the form-urlencoded Media Type
Subject: Re: Encoding the form-urlencoded Media Type
From: "Daniel W. Connolly" <firstname.lastname@example.org>
Date: Thu, 17 Aug 1995 14:52:58 -0400
Cc: Multiple recipients of list <email@example.com>
From firstname.lastname@example.org Thu Aug 17 14: 53:25 1995
In-Reply-To: Your message of "Tue, 15 Aug 1995 11:27:55 EDT." <9508140926.AA12867@venus.sirius.com>
X-Mailer: exmh version 1.6 4/21/95
In message <9508140926.AA12867@venus.sirius.com>, "Eric P. Scott" writes:
>draft-ietf-html-spec-05.txt (August 8, 1995) section 8.2.1 says:
> 1. The form field names and values are escaped: space
> characters are replaced by `+', and then reserved characters
> are escaped as per [URL]; that is, non-alphanumeric
>[My copy of RFC 1738 is dated December 1994!]
>I'm confused about the meaning of "reserved" in this context, or
>on exactly how much of [URL] is being incorporated by reference
>here--is it just the %HH encoding?
> I think the desired behavior
>is to encode space characters as `+'
> and `+' characters as %2B
>(note that [URL] considers `+' "safe!").
Exactly. + shouldn't be encoded, I believe.
> Looking at the just-
>released-to-the-public W3C WWWLibrary, HTEscape.c appears to let
>"-._" pass unencoded, but not the "safe" `$'; the "extra" `*' is
>O.K., yet none of its peers are.
This is a defect in WWWLibrary. I believe henrik already knows
about this. I'll copy email@example.com on this just in case.
>I think we're all in agreement that alphanumerics don't need to
>be encoded. Nowhere else in draft-ietf-html-spec-05.txt is
>there any mention of what constitute "reserved characters," but
>it seems that [URL]'s definition isn't applicable,
Why not? I believe [URL]'s definition is applicable. Hmmm...
it may be updated by [RELURL]. Roy?
> yet the
>reference implementation doesn't limit itself to strict
As I said, this is a bug. I'm pretty sure it's a known bug.