[duglin]

We don't actually say what should happen if the headers are not percent encoded the way the spec mandates. I'd like to suggest that we still allow the headers if they adhere to normal http processing and there are no other errors in them.

related to: #1397

[duglin]

Erik suggests just having the first sentence and dropping everything else (including the stuff below).

[duglin]

@jskeet given our spec is silent on what to do if people do not %-encode stuff (as a sender), it seems like we need to provide some level of guidance for receivers. Any thoughts?

[jskeet]

Hmm. Personally I've always favoured the approach of "be strict when receiving" as a way of encouraging everyone to do the right thing - I credit that as one reason why there's much less malformed XML in the world than malformed HTML (because XML parsers generally are strict). But I know that's not a popular position.

I think the most practical position is not to particularly require any stance: if you're working in a stack which fails automatically, that's fine, and you don't need to work around it to try to accept non-conformant events. If you're working in a stack which is more lax, then that's fine too. Basically I don't want to put too much work onto SDK owners, given that SDK owner time is pretty scarce.

[duglin]

@jskeet if someone produces a CE header that looks like this:

ce-Foo:    "word1    word2"

The spec, today, provides no guidance on what to do. I think it hurts interop (and the spec) to remain silent and then someone chooses to throw an error on this when it's perfectly valid per the HTTP spec. In this respect, I actually think CE has a bug by not allow a "normal" HTTP header value to be used.

What does the C# SDK do on this header?

[jskeet]

@jskeet if someone produces a CE header that looks like this:

ce-Foo:    "word1    word2"

The spec, today, provides no guidance on what to do. I think it hurts interop (and the spec) to remain silent and then someone chooses to throw an error on this when it's perfectly valid per the HTTP spec. In this respect, I actually think CE has a bug by not allow a "normal" HTTP header value to be used.

What does the C# SDK do on this header?

I couldn't tell you offhand, to be honest - I'd have to test it. I'm happy to do that, but not right now...

[jskeet]

Hmm... this is going to be slightly harder to test than I'd expected, because most tools are going to format the headers themselves. We already have an ASP.NET Core sample project to handle the .NET side of things. I might need to resort to netcat...

[jskeet]

Okay, I've now successfully sent a request - and the value of the foo attribute is word1 word2.

[duglin]

As expected, and as it should. I think there may be value in telling people this is the correct behavior rather than generating an error due to the lack of %-encoding.

I keep forgetting to mention that I think the spec is ambiguous wrt double-quotes. If they're encoded, are they passed on to the app or not? Are they used for grouping wrt commas? I think our attempt to ensure non-ascii chars are supported has resulted in making the simple cases harder/ambiguous.

[jskeet]

I'd expect encoded double quotes to be passed onto the app, but not grouping ones. Not sure about commas.

[shiva]

Where are we with this discussion.

1/ it would be useful to take a position on permissible vs non-permissible encoding.
2/ We should get the standard SDKs to conform with the spec. Since I am already looking at the javascript one, we can take this up next, once I get through the backlog of existing PRs.

P.S: I am in favour of allowing % encoding of space, and passing those through, whereas if the SDKs were used, they should encoding per the spec guidance and avoid this style of encoding. Can't prevent folks from using bad habits from the 80s nonetheless :)