splinter: status_code is only ever 200 - OK.

See attached testcase.

A status_code of 200 seems to be hard-coded since this commit?

https://github.com/cobrateam/splinter/commit/d151c565c1068c6f0ac3f09ff010353b9b1a9de2

import splinter

with splinter.Browser('firefox') as browser:
    # should be 200
    browser.visit('http://google.com')
    print(browser.status_code.code)
    print(browser.status_code.is_success())

    browser.visit('http://google.com/is_this_a_bug')
    print(browser.status_code.code)
    print(browser.status_code.is_success())

    browser.visit('http://github.com/is_this_a_bug/is_this_a_bug_project')
    print(browser.status_code.code)
    print(browser.status_code.is_success())

    browser.visit('http://this_domain_doesnt_even_exist.coma')
    print(browser.status_code.code)
    print(browser.status_code.is_success())

Gives this output:

$ python ./testcase.py 
200
True
200
True
200
True
200
True

This should be returning 404 for all but the 1st example.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 2
  • Comments: 15 (8 by maintainers)

Most upvoted comments

Someone mentioned this bug to me and I was puzzled as to why I hadn’t noticed it myself, and then realised it was because of the way I had structured my test cases: all my status code tests just use plain requests calls, without invoking splinter at all. I then only use splinter for interaction tests in the 200 OK case.

So +1 from me for having status_code raise NotImplementedError("Selenium WebDriver does not report HTTP status codes") (or some other appropriate message) in cases where the driver can’t set it reliably.

Multiple requests is difficult, POST requests are likely to not be idempotent, eg. the status code of a POST /create/user/jamesbond/ request the second time is very likely to be different to the first request. Even multiple GET requests could have effects so duplicating them probably does more harm than good.

Leave duplicated requests up to the application developer.

If there really isn’t a reliable way of getting the status code from the main request, I think NotImplementedError is the only sensible solution.