The bond REST api isn’t responding to connection headers. I have tried with close and keep-alive. It never responds with a connection header and does not respect keep-alive connections. HTML/1.1 spec is to leave the connection open unless the response contains connection='close'. Does anyone know why the API isn’t following this part of the spec? Am I missing something?
What are you trying to keep alive?
BPUP is the only thing I know of in the API that needs a keep alive, and it’s semi-unique to Bond, not leaning on any specific HTML standard. I’ve not had any issues implementing that, though I don’t have any connection headers involved in my calls.
All the other API aspects are pretty much just GET, PUT, POST, PATCH, etc - not sure what use keep alive would be in those one-and-done commands?
Of course, I could be very ignorant of where some would say a standard should exist and be followed, so I’m definitely curious to hear more about what use case you have in mind.
If someone else in the community, or a Bond staff member, wants to chime in with more insightful commentary, go for it, y’all! 
This isn’t related to bpup. I am referring to the local REST api. I have an extensive driver for SmartThings and it currently opens/closes the connection for every request. I am moving that driver to a library I wrote that allows for persistent http connections and realized that Bond isn’t sending the connection header in its http responses. Based on my understanding of HTTP/1.1, I believe it is required and the default is to leave the connection open. You can’t leave it open with the Bond because it will close its end of the connection.
So the use case was initially attempting a persistent http connection by sending connection=keep-alive with my requests. It reduces latency and is more efficient with resources. Had Bond responded affirmatively, the code would then issue multiple requests over the same shared socket. The bond is free to deny that request, but it doesn’t indicate either way. It really is just a point about the spec. I think they could send connection=close back all the time and be fine. Clients would then be able to properly close the connection.
Because it’s a hand-coded HTTP server that has the bare minimum (or, apparently, slightly less than the bare minimum).
I would agree with you. Section 6.1 of RFC 7230 states, in part:
A server that does not support persistent connections MUST send the
"close" connection option in every response message that does not
have a 1xx (Informational) status code.
And Section 6.3 states, in part:
HTTP/1.1 defaults to the use of "persistent connections"
Correct. After Bond sends the reply content, it calls close on the socket.
We should be able to do that easily. I’ve implemented, seems to work fine. Will try to get it into v3.19.3-beta tomorrow.
Later on, may be interesting to explore keep-alive or even pipelining for faster syncing.
2 Likes
@blueyetisoftware We’ve added the Connection: close header in v3.19.3-beta firmware, available now via the Beta channel in the app. :arigato-gozaimasu:
2 Likes
@merck Thank you for following up. It will be nice to cleanup up this connection code in the driver. On a related note, I would love to chat about making my Edge driver the official driver for Bond on SmartThings. It supports more devices than the default cloud connection, and is much faster. Let me know if you want to chat further.
1 Like
Sure. Wanna grab a time here? https://meetings.hubspot.com/chris-merck