Make WordPress Core

Opened 9 years ago

Closed 8 years ago

#32462 closed defect (bug) (duplicate)

Percent character using at Postname have a problem with IIS

Reported by: by-rallier's profile by rallier Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.2.1
Component: Formatting Keywords:
Focuses: Cc:


While postname have percent character, post slug auto generated not usable.
Custom Url options enabled.
IIS Url Rewrite enabled.
Postname : %100 work
Auto generated Post Slug : 0-is.html
link: visiting this link, redirect to and not found post at Blog

Change History (4)

#2 @JanR
9 years ago

Note: through this comment I'm trying to provide some more insights in this, on the web server level. The story below is tested on WordPress trunk (4.3-beta2-33249).

A first thought: IIS is a little whacky in what characters it allows in URL's. This is set through the HttpRuntimeSection.RequestPathInvalidCharacters property. The default set of invalid charachters is: <,>,*,%,&,:,\\ and this behaviour can be overwritten in the web.config file, in the httpRuntime node of system.web, e.g:

<httpRuntime requestPathInvalidCharacters=""/> (allowing all characters)
<httpRuntime requestPathInvalidCharacters="<,>,*,%,:,\,?"/> (keeping the default, but allowing %)

There are some caveats on allowing all characters though... And unfortunately, this won't fix this particular Post Slug problem in WordPress just yet.

Witnessed behavior after my first thought:
A post with the percent sign as first character (%100 work from the previous example) creates the Slug /0-work/. Copy pasting that slug (Edit in the Permalink) into a text editor like Notepad++ shows a DLE control character where the %10 was supposed to be.

So, in my opinion this is urlencoding gone bad and not an IIS error; ASCII character 10hex (or 16 decimal) is the DLE character. This is discussed in #25021.

Some more investigation because we want to get further:
After publishing, the slug /0-work/ is redirected to On its turn, IIS returns a HTTP 400 "Bad Request - Invalid URL", even with requestPathInvalidCharacters emptied in web.config. Probably due to the control character, of which we already established is there.

This is can some what be fixed by allowing double escaping in IIS Request Filtering module, if we urlencode % to %25. The URL does work. For this, set <requestFiltering allowDoubleEscaping="true" /> in the security node of system.webServer:

  <requestFiltering allowDoubleEscaping="true" />

Some examples:

Putting the % sign after 100 works, and gets filtered out. There is no difference in:

but fails as well, as a % somewhere around numbers creating other control characters will too.

Apologies for the long story.

This ticket was mentioned in Slack in #docs by janr. View the logs.

9 years ago

#4 @SergeyBiryukov
8 years ago

  • Component changed from Posts, Post Types to Formatting
  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Thanks @by-rallier for the report and @JanR for the extensive comment!

Sounds like a duplicate of #3329 and #25021, let's continue the discussion in the former.

Note: See TracTickets for help on using tickets.