Emma Brooks <me@xxxxxxxxxxx> writes: > It's also too vague and it's not entirely clear from the option itself > what sort of encoding it refers to. I will change it to > --[no-]q-encode-headers and format.qEncodeHeaders in v2 unless there are > other suggestions. I actually did not mean to push you into that direction. We can, and do want to, keep the most generic "--[no-]encode-headers" if we do not anticipate us wanting to special case the Q encoding. A sample question to ask is "would it make sense to disable q-encoding but still perform other parts of 'encode headers'?" I haven't thought deeply about such questions, but as a proposer of this topic, you would certainly have, and I was hoping that you'd say things like "Q-encoding is the only thing that we do to munge headers, so there aren't any 'other parts of encoding headers' we need to worry about", "there are things like X, Y and Z that we do to the headers when we enable Q-encoding, but they all are what we do not want when we do not want the Q-encoding", which would be a very good sign that assures us that "--[no-]encode-headers" is a good name. Thanks.
