background process fails on IIS without allowDoubleEscaping="true" in web.config [#1879052]

The colons in process handles (such as "uc:...") are double escaped and throw 400 errors of the form "A potentially dangerous Request.Path value was detected from the client (%)" under the default configuration of IIS. This contributes to Ultimate Cron having all processes appear hung and locked on IIS (they each silently fail with this 400 error). There are several possible workarounds:

Ensure all special characters are eliminated from handles, or
Remove rawurlencode where the url is later re-encoded by l() or similar (see line 122 of background_process.admin.inc), or

Modify IIS configuration to relax security:

<system.webServer>
  <security>
    <requestFiltering allowDoubleEscaping="true" />
  </security>
</system.webServer>

It looks like this issue has been addressed in your 7.x-2.x refactoring, but since that isn't yet offered as "production-ready" I'm submitting this in hopes of a backport.

Comments

Comment #1

gielfeldt CreditAttribution: gielfeldt commented 3 January 2013 at 19:32

Hi rymo

Thanks for the bug report. I don't have an IIS installation myself, so these reports are greatly appreciated.

Using the handle names as part of the URL path sure has given me more problems than I would have though possible, which is also why I abandoned this approach in 2.x.

However, simply encoding once will just create another problem, since encoded slashes '/' will then interpreted as a slash, thereby messing up the URL path (at least on Apache).

Also, I'm not sure a backport is possible, as this may break compatibility with 3rd party modules, so a major upgrade is the way to go, once I get around to finish 2.x.

Looking at your suggestions:

1.) I'm not sure how to eliminate the special characters safely, besides encoding them ... any suggestions?
2.) Not possible due to the above mentioned problem.
3.) This would probably be my current quick-fix for your situation.

I could also change the prefix in Ultimate Cron to not use a character that needs encoding (I'm thinking "uc_"?). This should at least make all cron jobs work. However, if some 3rd party module uses a handle that contains encoded characters, the problem will of course still persist there.

Thoughts?

Comment #2

rymo

he/him

CreditAttribution: rymo commented 3 January 2013 at 20:40

I replaced all instances of "uc:" with "uc___" and that seems to have fixed my problem without resorting to an IIS config change (though that was an effective quick-fix in my local dev environment) - but as you mention if I were to use some other third-party module this same problem might creep up again.