conjure-java-runtime
conjure-java-runtime copied to clipboard
Assert there's no BODY for http-code-200 responses for POST methods returning void
If a proxy decides to redirect the request to say an authentication service, then the caller gets back a 200 with some html BODY (the login page), even though the POST request definitely did NOT succeed.
If we're handling a POST that returns void and we get back a response with a BODY, http-remoting should force the http-error-code to be something like a 500.
This issue has been automatically marked as stale because it has not been touched in the last 60 days. Please comment if you'd like to keep it open, otherwise it'll be closed in 7 days time.
@pnepywoda have you encountered this in the last year?
It’s probably still an issue but I personally haven’t seen support tickets on it
On Mon, Oct 29, 2018 at 4:08 AM iamdanfox [email protected] wrote:
@pnepywoda https://github.com/pnepywoda have you encountered this in the last year?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/palantir/conjure-java-runtime/issues/573#issuecomment-433871484, or mute the thread https://github.com/notifications/unsubscribe-auth/ANQ9mB2K7oBrMvvvzkMkDe8zEL8I6H1Wks5upuGfgaJpZM4Pv1CW .
Let's re-open then until we have a test that proves this is fixed.
This issue has been automatically marked as stale because it has not been touched in the last 60 days. Please comment if you'd like to keep it open, otherwise it'll be closed in 7 days time.
Don't we require 204 response code for void methods?
Interestingly the wire spec doesn't seem to commit to either 200 or 204 for void response types: https://palantir.github.io/conjure/#/docs/spec/wire?id=_31-status-codes
oof, that breaks the way we handle backcompat in the java clients.
We expect that we can add an optional return type to a previously void method and vice-versa, but our clients decode 204 to empty optional, and validate 200 optional responses are present, which won't be the case for old "void" methods
This issue has been automatically marked as stale because it has not been touched in the last 60 days. Please comment if you'd like to keep it open, otherwise it'll be closed in 7 days time.