HTTP-based adapters should be allowed to customize their return http codes

[zubairhamed]

Currently, hono seems to implicitly return response directly to the client (e.g. http 200) and there seem not be a way to intercept this so that a custom http-based adapter could customize the http code being sent.

Use-case:
Sigfox, for example expects a 200 response if a downlink (up to 8 bytes of data to be sent to the device) is expected. If no downlink is expected (i.e. no data is to be sent to the device), a 204 should be sent.

[sophokles73]

@zubairhamed

is this only relevant for the case when the upload succeeds, i.e. if the REST adapter responds with a 204? Or do you need to be able to customize the responses to certain error cases as well, e.g. no more downstream credits, device unknown/disabled, no more device registration credits?

[zubairhamed]

Whoops sorry i overlooked your reply to this.

In the specific Sigfox case, its only interested in 200 (yes there is some downlink data) or 204 (nope. no downlink, just uplink). If data is not being sent across etc, you can send back an error like 500 or 404 and this would be shown to the administrator (i.e. the person owning the device) but it won't have any specific meaning to the Sigfox Backend itself.

Also I would imagine if the uplink from Sigfox to Hono fails (due to there being no credits), a downlink response is still warranted since a downlink message could have been sent to the adapter say..a day ago and since then all consumers may have left/disconnected BUT the downlink message still needs to be sent down.

Does that make sense?

[zubairhamed]

Hey Hono,

Do you folks have any updates on this issue?

Oh and a Happy New Year and here's to a successful 0.5!

Z

[sophokles73]

Hi @zubairhamed,

there is currently no one working on this. I think we could address this issue as part of 0.6 where we also want to add support for Gateways publishing data on behalf of other devices (#416).

[sysexcontrol]

Hi @zubairhamed ,

we would like to support the Use case described by configuration options of the HTTP adapter.
This would enable HTTP clients (Sigfox in your case?) to receive response codes 200 (if there is a command contained) or 204 (if there is no command) to telemetry/event messages.

Currently there would be no case where an error status code returns a command (but this might change in the future).

Since the change is so small, we do not think it is worth to enforce a custom adapter to achieve this, but rather make the returned status code configurable per tenant for:

• message successful, command is included
• message successful, no command was pending

Would this solve your issue?

[zubairhamed]

Hey Karsten,

I can test this out if this works with 0.6 but yep from the sound of it i believe it does solve it.

Z

[sysexcontrol]

Hey Z,

cool, thanks for the reply.
Just let me note that (of course) 0.6 would have to be slightly modified in the code to test it out, since 0.6 always responses with 202 Accepted.
But that should be the minimal viable problem, I guess ;-)

Let me know if I can assist (or if I shall provide the patch for 200 and 204 in a branch to let you focus on the test).

[sysexcontrol]

Hey again Z,

I just provided a branch called honoSigfoxBranch (https://github.com/eclipse/hono/tree/honoSigfoxBranch), which is hardcoded to 200 resp. 204 as discussed above.
You can use this branch for the tests with Sigfox, I am curious to hear again from you after that!

Let me know if you need further assistance.

[sysexcontrol]

@zubairhamed : any news regarding this issue?
If not, we would remove this from the 0.7 milestone during this week.