I have just come across a problem with url's with "+"
characters in them (which means they should be looking for
a space in the filename on disc). It seems they are no
longer converted to spaces by IIS and IIS returns a 404
error (no such file). I am sure this used to work
correctly a couple of months ago.

They are not being treated as "+" characters either. The +
characters are infact generated by MS Content Management
Server 2000.

Has anyone else noticed this problem, could it be caused
by a recent security patch.

Re: + in url no longer converts to <space> by David

David
Fri Nov 07 20:47:07 CST 2003

Which part of the "URL" are you referring to?

In the URI-stem, a + character needs to be %-encoded
In the Querystring, a + character can be left as is.

In the GET case of a FORM, the form variables are stored in the Querystring,
and a + is supposed to mean space.


Thus, IIS *never* treats a + anywhere in the URL as a space when
interpreting a URL as a file. If it worked for you before, it is either not
through this mechanism or it is not done by IIS.

Now, it is possible to write an extension to IIS that has the semantics you
are talking about (i.e. interpret + as a space), but then your problem is
with that extension and not IIS. For example, it is possible that you have
some extension to IIS that uses the querystring to denote a filepath to
open, and it can choose to interpret + in the querystring as space and open
the file.

Thus, you must tell me where the + character exists -- in the URL-stem,
PathInfo, Querystring, Header, or Entity Body.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Fred" <fred.rayers@uk.consulting.fujitsu.com> wrote in message
news:009f01c3a561$1b362590$a501280a@phx.gbl...
I have just come across a problem with url's with "+"
characters in them (which means they should be looking for
a space in the filename on disc). It seems they are no
longer converted to spaces by IIS and IIS returns a 404
error (no such file). I am sure this used to work
correctly a couple of months ago.

They are not being treated as "+" characters either. The +
characters are infact generated by MS Content Management
Server 2000.

Has anyone else noticed this problem, could it be caused
by a recent security patch.