New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

On POST creation, 201 status with a Location header should not fail #3171

Closed
jterry opened this Issue Jun 3, 2016 · 3 comments

Comments

Projects
None yet
3 participants
@jterry

jterry commented Jun 3, 2016

In the case of a POST interaction, InnerBrowser is aggressively evaluating a redirection response header, and evaluating a response as a failure if the browser is not redirected.

In this particular case, a Location header doesn't indicate a redirection, but instead indicates the location of the created record (defined in boring detail in RFC2616, 10.2.2).

Would there be other issues I'm not seeing by also checking for an HTTP status code of 201 and not interpreting the Location header as a redirect? Even better than that, check for no status code or a 3xx code and then evaluate the purpose of the header?

As a side note, 2.2.1 sees the issue, but 2.1.10 does not.

@DavertMik

This comment has been minimized.

Show comment
Hide comment
@DavertMik

DavertMik Jun 7, 2016

Member

Thanks. Probably I encountered this as well. We will try to fix it today

Member

DavertMik commented Jun 7, 2016

Thanks. Probably I encountered this as well. We will try to fix it today

@jterry

This comment has been minimized.

Show comment
Hide comment
@jterry

jterry Jun 7, 2016

Thanks @DavertMik and @Naktibalda! Really enjoying the framework - it's a phenomenal improvement for us consolidating testing.

jterry commented Jun 7, 2016

Thanks @DavertMik and @Naktibalda! Really enjoying the framework - it's a phenomenal improvement for us consolidating testing.

Naktibalda added a commit to Naktibalda/Codeception that referenced this issue Jun 7, 2016

DavertMik added a commit that referenced this issue Jun 7, 2016

@DavertMik DavertMik closed this Jun 7, 2016

@DavertMik

This comment has been minimized.

Show comment
Hide comment
@DavertMik

DavertMik Jun 7, 2016

Member

Will also merge into 2.2

Member

DavertMik commented Jun 7, 2016

Will also merge into 2.2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment