This question is related to another question I asked:

Links from wildcard tag search results returning 404.

The setup looks like this:

  1. Click on a wildcard tag which matches a large number of tags (I'm using django~).
  2. Click to go to the next page of results.
    • The "Newest", "Featured", etc, links at the top produce the same 400 error code.

The link being produced looks like this:


From my previous question, Jeff stated that he would be limiting the number of tags coming back from a wildcard explode, so I assume that 20 is the limit since there are ~50 tags which begin with 'django', so that seems to be working as intended.

I also ran into this question, in which Jeff says that the maximum number of characters in the URL has been set to 512. The URL above which does not work is 425 characters long, so I do not believe this limitation is being run into either.

The construction of this link also seems to leave something to be desired. From what I can discern of the URL, the second page of questions will not include questions tagged with django-fields, django-errors, or django-csrf, because they are not listed in the or string on the URL.

In order to make the functionality work on django~ tags, I've had to resort to editing the URL to re-use the wildcard flags. To view the second page of results, this link works:


It seems to me that the constructed string of tags is creating the issue. Would it be possible to allow the page to simply reference the existing wildcard tag, instead of concatenating all of the exploded tags into the URL?

Ninja Edit:
I believe this will also end up being related to this question:

More wildcard tag bugs - adding a related tag causes 400 error

2 Answers 2


Wildcard paging is now much cleaner and will avoid these "url too long" errors as a result. For example visiting [django*], the paging (and tab links) is now like this:


Meaning we don't expand the tag list before using it elsewhere. Also, ~ or * will work as a wildcard (due to a restriction lifted in .Net 4.0), either of these will continue to work on our site.


You need to use the querystring format as specified.


I've modified that setting, but it's unclear where in the pipeline this is getting rejected (IIS, etc). So for now, you need to use the workaround.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .