HTTP connection header support not to spec?

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! :smile:

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.