Tcl

backport to http 2.7.5 (distributed with Tcl 8.5.8)
completed.

sorry about the bad advice. I had forgotten
that the http packages on the 8-5 and 8-6
branches had already diverged.

Yes, I am planning to backport this, but I cannot do it until tonight. Don,
feel free to do it, if you are waiting for it in order to complete the
8.5.8 release.....

I see that you committed a fix for this. Are you going to backport?

I hereby withdraw my objection :-) ... I read through the RFCs and it seems
I indeed had the wrong impression that there is a strict definition of the
last part of the URL notation.

-- Matthias Kraft

When the strict uri checking code went in (during 8.5 development iirc) it
got a -strict option added to disable it. So http::geturl $uri -strict 0
will probably have let you work with this as it stands.
However, I would support changing this to match the URI rfc as you've
quoted below. We are evidently being too strict.
No objection.

nijtmans, please commit your patch
to go in http 2.7.4 distributed with
Tcl 8.5.8 and 8.6b2. Thanks.

So, I am glad I brought this up. So many reactions. Thanks all!

Answerings: Yes Firefox and other browsers behave the same
way. No browser does automatic URL-encoding. They all
pas through the exact URL given.

No, I cannot get the server fixed. RFC 1738 is
indeed rather misleading in the interpretation
of what is allowed in the <query> part of an URL.

Lucky enough, RFC 3986 has a much clearer
description, which convinced me that multiple
question marks are allowed in a quiery. Citing:
this RFC:

===================================
3.4. Query

The query component contains non-hierarchical data that, along with
data in the path component (Section 3.3), serves to identify a
resource within the scope of the URI's scheme and naming authority
(if any). The query component is indicated by the first question
mark ("?") character and terminated by a number sign ("#") character
or by the end of the URI.

query = *( pchar / "/" / "?" )

The characters slash ("/") and question mark ("?") may represent data
within the query component. Beware that some older, erroneous
implementations may not handle such data correctly when it is used as
the base URI for relative references (Section 5.1), apparently
because they fail to distinguish query data from path data when
looking for hierarchical separators. However, as query components
are often used to carry identifying information in the form of
"key=value" pairs and one frequently used value is a reference to
another URI, it is sometimes better for usability to avoid percent-
encoding those characters.

I am also against such a move. If this is really needed and going to be
implemented, please ensure it either has to be explicitly switched on, or
can at least be switched off...

-- Matthias Kraft

Can't you get the server fixed?

Does it work in any browser other than IE? If not, it's just a broken site
and we shouldn't introduce breakage into the http package just to allow for
this one stupidity.

As evidence, I cite RFC 1738 which states that "?" is one of the reserved
characters in the <searchpart> (the part of the query after the first "?"
character).

>A '?' in the request parameter should be encoded as '%3f'.

Yes, that was my first though too. But in this case, the question
mark is not used as a value, it is a separator, so encoding
it as %3f does not work with this service.

A '?' in the request parameter should be encoded as '%3f'.