Invalid Content-Length header returned by REST API

[yitzhaq]

Does the issue really belong here?

• I definitively want to report a bug within deCONZ or its REST-API

Is there already an existing issue for this?

• I have searched the existing issues and there is none for the bug at hand

Describe the bug

The webserver returning content for the REST API returns an invalid value for the Content-Length header. Specifically, it lacks a space before the value.

Steps to reproduce the behavior

Easily reproduced with cURL:

$ curl -I "http://localhost:8080/"
HTTP/1.1 301 Moved Permanently
Content-Type: text/html
Location: /pwa/index.html
Content-Length:104

The error is seemingly exhibited on all endpoints:

$ curl -I "http://localhost:8080/pwa/index.html"
HTTP/1.1 200 OK
ETag: KCJZNkBpoESqOR5CKcvZ7g==
Content-Type: text/html; charset=utf-8
Content-Length:520310
Cache-Control: max-age=300
Keep-Alive: timeout=6
Last-Modified:Mon, 07 Oct 2024 13:25:58 G10T

And irrespective of verb:

$ curl -svo /dev/null "http://localhost:8080/pwa/index.html"
*   Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /pwa/index.html HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.88.1
> Accept: */*
> 
< HTTP/1.1 200 OK
< ETag: KCJZNkBpoESqOR5CKcvZ7g==
< Content-Type: text/html; charset=utf-8
< Content-Length:520310
< Cache-Control: max-age=300
< Keep-Alive: timeout=6
< Last-Modified:Mon, 07 Oct 2024 13:25:58 G10T
< 
{ [32768 bytes data]
* Connection #0 to host localhost left intact

Expected behavior

Content-Length header should include the mandatory space to make it valid:

Content-Length: 520310

Environment

• Host system: Raspberry Pi
• Running method: Raspbian
• deCONZ version 2.29.1-beta

[SwoopX]

Hi,

not sure I can follow here. Why is that supposed to be invalid please? And what's the impact of that?

[manup]

Good catch, not sure if it was really invalid or browsers just being tolerant on it.
But usually behind the <header>: there is a space, I've fixed that in above commit.

[yitzhaq]

@manup Thanks. Sorry I didn't catch this sooner, but the Last-Modified header also seems to be exhibiting the same behavior, as seen in the example above.

[SwoopX]

This is no bug at all as functionality is not impacted. RFC 7230 yields that the referred to space is optional.

Just saying...

[yitzhaq]

This is no bug at all as functionality is not impacted. RFC 7230 yields that the referred to space is optional.

Just saying...

Indeed this is not strictly a spec violation, but rather an invocation of Postel's law. Some clients are less tolerant of the less common non-spaced version, so the robustness principle would suggest including it, while also answering the question of how functionality is impacted. This is certainly true when the omission is neither deliberate nor consistent, which should also serve to make any possible argument concerning bug compatibility moot (the change is not against spec).