I am writing a small application that emulates electrical meters like the Everhome EcoTracker. Therefore, I am using Pekko and Pekko Http.
The emulated EcoTracker device has the absolute non-standard behavior of not providing a Date header field in its HTTP responses. I guess the main reason for that is that the device has no date/time information. Unfortunately, some battery storages rely on an HTTP response with exactly the two HTTP header fields content-type and content-length.
With the current Pekko HTTP version, I am not able to suppress the Date header field. It is always automatically added. I am thinking about an additional configuration parameter that allows suppressing the Date header in a similar manner as it is possible with der Server header field.
I would volunteer to implement that feature and provide a PR. I just wanted to first check if such a PR has the chance to be accepted or if it would be refused since such a behavior is absolutely non-standard.
I am writing a small application that emulates electrical meters like the Everhome EcoTracker. Therefore, I am using Pekko and Pekko Http.
The emulated EcoTracker device has the absolute non-standard behavior of not providing a Date header field in its HTTP responses. I guess the main reason for that is that the device has no date/time information. Unfortunately, some battery storages rely on an HTTP response with exactly the two HTTP header fields content-type and content-length.
With the current Pekko HTTP version, I am not able to suppress the Date header field. It is always automatically added. I am thinking about an additional configuration parameter that allows suppressing the Date header in a similar manner as it is possible with der Server header field.
I would volunteer to implement that feature and provide a PR. I just wanted to first check if such a PR has the chance to be accepted or if it would be refused since such a behavior is absolutely non-standard.