Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

status_code is only ever 200 - OK.

See original GitHub issue

Issue Description

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.

Issue Analytics

State:
Created 7 years ago
Reactions:2
Comments:15 (8 by maintainers)

Top GitHub Comments

1reaction

ncoghlancommented, Jul 18, 2017

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.

1reaction

samuelcolvincommented, Jul 9, 2017

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.