-
Notifications
You must be signed in to change notification settings - Fork 433
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
Make 408's not result in orphan mitigation #456
Conversation
Hey duglin! Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you and the commit authors have already signed the CLA. |
While we could technically merge the two 4xx lines, I think its important to call out the 408 by itself so we can be clear that this is a "client side" timeout and not a "server side" one - which are very very different w.r.t. orphan mitigation |
TBH I would prefer to remove the special mention of |
@nilebox my original version of the PR did merge them and within 5 minutes I got a ping about it because the distinction between client-side vs server-side timeout wasn't clear - so I added it back in, just for the sake of clarity. We don't need to call-out |
@duglin I see your concern, but the distinction between client-side and server-side errors is an HTTP standard's problem, OSB doesn't bring anything additional there. Furthemore, HTTP standard makes the distinction very clear - |
@@ -1430,7 +1430,7 @@ Platforms SHOULD initiate orphan mitigation in the following scenarios: | |||
| 201 | Success | No | | |||
| 201 with malformed response | Failure | Yes | | |||
| All other 2xx | Failure | Yes | | |||
| 408 | Timeout failure | Yes | | |||
| 408 | Client timeout failure (request not received at the server) | No | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand the usage of 'server' here. A client could get a 408 by having it's local timeout setting very small. Or you could be talking to a broker proxy and the second connection could timeout. Both cases could result in orphans. I am not sure how a broker author could prevent their implementation from returning a 408 AND/OR make sure that orphans are not possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
perhaps "receiver" would be better, but in the other cases you mentioned I'm not sure the Platform would see a 408. As long as the message makes it to the next hop I don't think 408 would be appropriate. And I would think that hop before that one would return a 5xx since from its POV it did receive the entire request so it can't be a 408. Right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking up 408 in the rfc...
Ok I agree. In this case, server is fine with me.
reviews needed |
1 similar comment
Signed-off-by: Doug Davis <dug@us.ibm.com>
2 more reviews needed |
/cc @nilebox
Closes #449
Signed-off-by: Doug Davis dug@us.ibm.com