3

I have a website that takes two primary get strings:

?type=GAME&id=SomeGameID
?type=SCENARIO&id=SomeScenarioID

for reasons unknown, I have recently begun receiving requests for erroneous get strings from both Yandex and Baidu. They are always in the form of:

?type=GAME&id=SomeScenarioID

None of my users are triggering these errors, so I am (sort of) confident that this is not due to an HTML template error somewhere on my part. There is also no HTTP_REFER showing up in the $_SERVER array, so I'm guessing these are direct requests from bad dbase data on their part.

I see two options for dealing with these bad requests, and would like to know which is recommended... or if there are other, better options I have not thought of:

  1. simply 404 the request, since it is incorrect
  2. redirect the request to ?type=SCENARIO&id=SomeScenarioID because the scenario IDs are always valid, the breakage is due to asking for the wrong type.
Improve this question
2
  • Going by your second solution, why do you even need to specify the type=? If scenario and game IDs are mutually exclusive, there's no need to classify them. However, you may want to use a 404 for security, hindering a user from manually trying to access a game or scenario by guessing ID numbers.
    – Hand-E-Food
    Oct 23, 2012 at 1:44
  • @Hand-E-Food - I separate them because they are stored in different tables in the database and have very different properties. By receiving a type my code knows which table to query, and which class to create an object from. It simplifies things for me without adding any overhead to the UX.
    – Drew
    Oct 23, 2012 at 1:58

3 Answers 3

Reset to default
7

I would stick with rejecting the request, however as the url being requested does exist, the error code 400 seems more appropriate.

From the w3 http/1.1 standards:

10.4.1 400 Bad Request

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

Improve this answer
4
  • oooh, code 400, very nice! That will hopefully help them clean up their bad data rather than repeatedly ping for these false links.
    – Drew
    Oct 23, 2012 at 5:19
  • 1
    "the url being requested does exist" - no, it clearly does not. URL includes querystring, and the user is requesting a GAME resource which does not exist. Hence, 404 is the correct status code. 400 says the request syntax is bad, which it is not.
    – Misko
    Oct 23, 2012 at 19:45
  • @Chris - it is not at all clear cut. You could make an argument that this is a request against a primary URL (which exists!) made with invalid query parameters. The specification of the HTTP response codes is sufficiently rubbery that either 400 or 404 is justifiable. And if this is sufficient to fend off unwanted crawler requests, then that is ample justification ... no matter what the spec says.
    – Stephen C
    Oct 25, 2012 at 7:43
  • 1
    @StephenC: URL means Uniform Resource Locator. The resource being "located" is a particular game entity which does not exist, so the status code should reflect that. There is nothing "rubbery" about "The request could not be understood by the server due to malformed syntax". This clearly does not describe the issue at hand. I don't see why a crawler would repeat a request that results in 404 and more than it would for 400. However, the 400 error may confuse legitimate users who are actually looking for a game.
    – Misko
    Oct 25, 2012 at 14:22
2

I would favor 404 over 400 in this situation. 400 means the request is malformed, but the request you described is not malformed. The request is for a GAME that does not exist; this is the definition of error 404.

If there were a way to know: the request is for a GAME, but the ID given is clearly a scenario ID, then this would constitute malformed syntax. However, based on your statements in the comments, there is no discernible difference between game IDs and scenario IDs. The game ID being requested is a valid ID, it simply doesn't exist.

This is the same reason your redirect idea would not be good. You can't know that someone is actually looking for a SCENARIO if they have specifically asked for a GAME. If a consumer asked for a GAME but accidentally passed a bad ID and got redirected to a SCENARIO, they would be terribly confused.

Improve this answer
1

I concur that 400 is a better response than 404.

When you say "I'm guessing these are direct requests from bad dbase data on their part". I interpret that as meaning that the requests are coming from web crawlers. If that is the case, then another alternative would be to configure your site's robots.txt file to tell the Yandex and Baidu crawlers to stay out of the part of your site with the queries. Or maybe just block them.

Assuming that this is crawler activity, the problem might not be bad data (which would have had to come from somewhere). It is possible that the engines are trying alternatives in a rather lame fashion in order to harvest stuff that isn't directly linked. (It sounds like a stupid thing to do, but you never know ...)

On the other hand, if this is not web crawler activity, perhaps it is the result of some users trying to access your site using some custom client rather than using the UI implemented by your web templates. That would also explain the lack of referrer headers.

Improve this answer
1
  • it's all crawlers - just Yandex and Baidu so far, not google.
    – Drew
    Oct 24, 2012 at 8:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.