Azure-iot-sdk-c: HTTP transport failure when using space in the Map_AddOrUpdate key

Created on 3 Nov 2017  路  5Comments  路  Source: Azure/azure-iot-sdk-c

  • OS and version used:

  • SDK version used: <1.1.26>

Description of the issue:


When creating a message to send to the iot hub using the HTTP protocol, I used the Map_AddOrUpdate to add some parameters. The key that I used contained a space as shown below. The iot client failed to send the message to the IOT hub.
It might be a requirement to not use spaces in the map key string, however it is not specified in the documentation.

Code sample exhibiting the issue:

if (Map_AddOrUpdate(propertyMap, "Message Type", "TestMessage") != MAP_OK)

Console log of the issue:

Error: Time:Fri Nov  3 10:53:28 2017 File:/media/extended/jenkins/jobs/IOT-Device-SDK/workspace/azure-iot-sdk-c/c-utility/src/httpheaders.c Func:headers_ReplaceHeaderNameValuePair Line:98 (result = HTTP_HEADERS_INVALID_ARG)
Error: Time:Fri Nov  3 10:53:28 2017 File:/media/extended/jenkins/jobs/IOT-Device-SDK/workspace/azure-iot-sdk-c/iothub_client/src/iothubtransporthttp.c Func:DoEvent Line:1567 unable to HTTPHeaders_ReplaceHeaderNameValuePair
Error: Time:Fri Nov  3 10:53:30 2017 File:/media/extended/jenkins/jobs/IOT-Device-SDK/workspace/azure-iot-sdk-c/c-utility/src/httpheaders.c Func:headers_ReplaceHeaderNameValuePair Line:98 (result = HTTP_HEADERS_INVALID_ARG)
Error: Time:Fri Nov  3 10:53:30 2017 File:/media/extended/jenkins/jobs/IOT-Device-SDK/workspace/azure-iot-sdk-c/iothub_client/src/iothubtransporthttp.c Func:DoEvent Line:1567 unable to HTTPHeaders_ReplaceHeaderNameValuePair


area-documentation

Most helpful comment

Hi @bakarydiarra ,
this issue is for sure bug, we just need to verify on our specs the original expected behavior to confirm where. It might end up being:

  1. Lack of documentation mentioning the restriction on spaces, and
  2. Lack of validation on the IoTHubClient for spaces (it should fail right away), and
  3. Incorrect behavior of HTTP transport attempting to resend the improperly formatted message,
    or
  4. Lack of url-encoding of the properties key and/or value before they get processed.

We will come back to you soon with the course of action.

All 5 comments

Hi @bakarydiarra ,
this issue is for sure bug, we just need to verify on our specs the original expected behavior to confirm where. It might end up being:

  1. Lack of documentation mentioning the restriction on spaces, and
  2. Lack of validation on the IoTHubClient for spaces (it should fail right away), and
  3. Incorrect behavior of HTTP transport attempting to resend the improperly formatted message,
    or
  4. Lack of url-encoding of the properties key and/or value before they get processed.

We will come back to you soon with the course of action.

This issue is to some degree related to #257 (both would require adding url-encoding/decoding capabilities)

For HTTP, we do not support spaces in the key names because these turn directly into HTTP header names which aren't allowed.

We're going to add additional documentation to this and #257 so it's more clear up front; agree this is necessary.

I've clarified the docs / comments on this in ae7871abe80e5633962473d3eed8572e6a64e45b.

Ideally we would just have the message object fail as soon as a space were detected in it if we were going over HTTP. The message "object" doesn't know which transport its destined to be sent over (since we don't want to couple these together) and other transports do allow spaces, so we can't put the logic there.

@bakarydiarra, thank you for your contribution to our open-sourced project! Please help us improve by filling out this 2-minute customer satisfaction survey

Was this page helpful?
0 / 5 - 0 ratings