We are getting a "page not found" error on the "Custom product report" page when we try to retrieve a report for more than one status at a time. Here is a sample of the generated URL that creates the error:
https://www.domain.tld/admin/store/reports/products/custom/1296432000/1328918399/payment_received%252Ccompleted

A quick search for that "%252C" character encoding at the end of the URL suggests that in other software this can sometimes result from a double escape error in the URL generator. And that the "25" in "%252C" may actually be a duplicate percent sign. See for e.g.:

What standard produced hex-encoded characters with an extra “25” at the front? [stackoverflow.com]:
http://stackoverflow.com/questions/8348197/what-standard-produced-hex-en...

And indeed, if I replace that character string with just "%2C" in the URL, then the product report appears correctly, including both statuses.

We are running a Microsoft IIS 7.x web server if that makes any difference. And we are using ISAPIRewrite instead of web.config (or Apache mod_rewrite + htaccess) to achieve clean URLs.

Phil.

Comments

longwave’s picture

I noticed the double encoding a while ago but everything works as expected on Apache, so I guess the 404 must be due to IIS. Changing this now would mean breaking existing bookmarked URLs, but perhaps we can retain backward compatibility somehow.

pkiff’s picture

Mmmm...thanks for the hint to look at IIS. Maybe it is indeed an issue with how we've got our IIS configured. There is a setting available in the IIS "web.config" file (also available through the IIS manager GUI) that controls whether to allow double-escaping or not.

If I set it to true, then the "bug" I've identified goes away. When set to false, it re-appears. I am unclear on what the default setting is. I don't see a reference to this value in the Acquia version of the web.config file for Drupal 6 (which is often used as a reference point for Drupal 6 web.config code). Nor is there a reference in the web.config that comes included with Drupal 7. However, in various places on the web, there are various suggestions that you will need to set this in IIS 7. For example:
http://learn.iis.net/page.aspx/296/top-10-changes-in-iis7/
and iis-aid suggests you will need it with Drupal:
http://www.iis-aid.com/articles/how_to_guides/using_drupal_microsoft_url...

Here is the most common method for setting this value:

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

This setting also affects URLs that include a plus sign (+), so I expect it affects other modules here and there.

There is presumably an increased security risk on an IIS server if you allow double escaping in URLs, but as long as you are only running Drupal sites on the server, then I expect there is no real-world decrease in security. If you are running a mix of Drupal sites with other sites that include PHP/JavaScript/etc. on the same server then you may very well be increasing your security risk.

I would assume that the right, long-term solution would be to rewrite the code to remove the double-escaping. But this solution works for us for now. In another year we will probably be moving everything to Drupal 7 anyways.

Phil.

tr’s picture

Category: bug » support

Also see:
http://drupal.org/node/686982
http://drupal.org/node/799304

This seems to be an IIS 7 incompatibility with Drupal, not an Ubercart issue.

%252C is the double-encoded version of ','. Single encoding is %2C, double-encoding changes the % to %25 resulting in %252C.

longwave’s picture

Status: Active » Fixed

Marking fixed based on the above. A patch to change the double encoding behaviour would be welcome, but as IIS seems fairly rare in combination with Ubercart, the maintainers probably won't fix this otherwise.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.