Host Header missing in notification

[sjerman]

Hi. I just spent a while trying to figure out why tomcat was returning 400 silently for each notification sent. Looks like the Host header is needed.

This is the subscription:

{
   "id":"urn:ngsi-ld:subscription:1af7864c-c949-11ed-8416-0242ac140003",
   "status":"active",
   "origin":"cache",
   "watchedAttributes":[
      "value"
   ],
   "description":"Notify me of change sets",
   "type":"Subscription",
   "entities":[
      {
         "type":"BinarySensor"
      }
   ],
   "notification":{
      "attributes":[
         "value",
         "pointId"
      ],
      "format":"keyValues",
      "endpoint":{
         "uri":"http://192.168.1.108:8080/test/events",
         "accept":"application/json"
      },
      "status":"failed",
      "timesSent":2,
      "lastNotification":"2023-03-23T07:15:50.680Z",
      "lastFailure":"2023-03-23T07:15:50.680Z",
      "consecutiveErrors":2,
      "lastErrorReason":"non 2xx response to notification"
   },
   "isActive":true
}

This is the payload sent:

POST /test/events?subscriptionId=urn:ngsi-ld:subscription:1af7864c-c949-11ed-8416-0242ac140003 HTTP/1.1
Content-Length: 314
Content-Type: application/json
User-Agent: orionld/post-v1.1.0
Accept: application/json
Ngsild-Attribute-Format: Simplified
Link: <https://registry.kloudspot.com/repository/files/fiware/datamodels.context-ngsi.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"

{"id":"urn:ngsi-ld:Notification:1c9f2ce8-c949-11ed-ad65-0242ac140003","type":"Notification","subscriptionId":"urn:ngsi-ld:subscription:1af7864c-c949-11ed-8416-0242ac140003","notifiedAt":"2023-03-23T07:05:36.832Z","data":[{"id":"urn:ngsi-ld:BinarySensor:001","type":"BinarySensor","pointId":"docker","value":true}]}

A 400 error is returned by tomcat before it gets to the application level...

Note no header...

I can simulate this with CURL..

curl -v http://192.168.1.108:8080/test/events?subscriptionId=urn:ngsi-ld:subscription:1af7864c-c949-11ed-8416-0242ac140003 \
   -H 'Content-Type: application/json' \
   -H 'Accept: application/json' \
   -H 'Ngsild-Attribute-Format: Simplified' \
   -H 'Link: <https://registry.kloudspot.com/repository/files/fiware/datamodels.context-ngsi.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
   -d '{"id":"urn:ngsi-ld:Notification:1c9f2ce8-c949-11ed-ad65-0242ac140003","type":"Notification","subscriptionId":"urn:ngsi-ld:subscription:1af7864c-c949-11ed-8416-0242ac140003","notifiedAt":"2023-03-23T07:05:36.832Z","data":[{"id":"urn:ngsi-ld:BinarySensor:001","type":"BinarySensor","pointId":"docker","value":true}]}'

works

curl -v http://192.168.1.108:8080/test/events?subscriptionId=urn:ngsi-ld:subscription:1af7864c-c949-11ed-8416-0242ac140003 \
   -H 'Content-Type: application/json' \
   -H 'Accept: application/json' \
   -H 'Host:' \
   -H 'Ngsild-Attribute-Format: Simplified' \
   -H 'Link: <https://registry.kloudspot.com/repository/files/fiware/datamodels.context-ngsi.jsonld>; rel="http://www.w3.org/ns/json-ld#context"; type="application/ld+json"' \
   -d '{"id":"urn:ngsi-ld:Notification:1c9f2ce8-c949-11ed-ad65-0242ac140003","type":"Notification","subscriptionId":"urn:ngsi-ld:subscription:1af7864c-c949-11ed-8416-0242ac140003","notifiedAt":"2023-03-23T07:05:36.832Z","data":[{"id":"urn:ngsi-ld:BinarySensor:001","type":"BinarySensor","pointId":"docker","value":true}]}'

doesn't

Just FYI... I think it is now a required header:
https://www.rfc-editor.org/rfc/rfc9110.html#name-host-and-authority

[kzangeli]

ok, easy fix. I'll just add the host header then :)

[kzangeli]

Thanks for reporting!!!

[sjerman]

Thanks for fixing :)

…

On Thu, 23 Mar 2023 at 09:51, Ken Zangelin ***@***.***> wrote: Thanks for reporting!!! — Reply to this email directly, view it on GitHub <#1343 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAZ37SPDYRX36DR57PFLK5LW5QMIRANCNFSM6AAAAAAWE2E26E> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[kzangeli]

Should be working now.
I take as hostname what "gethostname" gives back.
I could let the users decide by adding a CLI for it, jsut not sure that's a very good idea ...

Test it and if all is good, please go ahead and close this issue.
And if not, just describe what's not good and I'll try to fix it.

[sjerman]

Sorry for the delay. This is fixed. Thanks.