Adding header to previous empty value results in incorrectly formatted message

[huw1990]

If you add a header with a non-empty value to a message containing the same header with an empty value, the result is an incorrectly formatted message. For example, given an existing message of:

...
Supported:
...

Adding a "Supported: timer" header to that message results in the following:

...
Support: ,timer
...

It's a reasonable expectation for the value to be "Supported: timer" after adding the new header, since it's effectively overwriting the initial empty value of "no extensions are supported" as specified in RFC 3261, section 20.37.

[vladimirralev]

Yep I see. Thanks for the report.

[huw1990]

Thanks for the fix. It looks like the AcceptLanguageParserTest is broken as a result of these changes.

[vladimirralev]

Yes, this is a bit of a complicated situation. I am away for a couple of days, will check it out on Wednesday.

[vladimirralev]

Just adding this here for consideration.

The Accept-Language request-header field is similar to Accept, but
restricts the set of natural languages that are preferred as a
response to the request.

      Accept-Language = "Accept-Language" ":"
                        1#( language-range [ ";" "q" "=" qvalue ] )

      language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )

The test is technically illegal, but the stack shouldn't enforce legality of this header to support use-cases related to broken clients and creation of torture tools meant to test 3rd parties against reasonably malformed headers.

Combined with the fact that this test is in the TCK which is the spec benchmark we can give it more weight towards the freedom.

I am curious if your use case could get away gracefully by using the setHeader() method. Semantically it may be more consistent to do something like which would overwrite previous headers:

SupportedHeader support = protocolObjects.headerFactory
                    .createSupportedHeader("timer");
request.setHeader(support);

[huw1990]

Our use case is to add extra Supported header values on top of what was already provided, rather than overwriting and replacing with our own. We could workaround this by querying for this specific case of an empty header value, it just seemed like something that would be better to handle in the stack, since adding a non-empty value to an already empty value is accepted, but produces an invalid message.