Draft: draft-ietf-quic-http

Commentary: if we want to do that . There was a hole in the error code space , so I filled it with this . I have n't pulled  out to its own error ; it does n't seem like it belongs with this one . 
 We might want to add a mention of this in A.4 where we talk about PROTOCOL_ERROR 
 ( I could n't find anything on this , but I 'm prepared to be corrected . Also , it 's late , so if this is closed , I 'm totally OK with that . ) We 're just in the process of doing full validation of pseudo - header fields ( I know , seems late , what are you gon na do about that ) . And we realized that there is no error code for indicating this sort of error . That is , if pseudo - fields are out of order , or a request contains , or there are uppercase characters . contains lots of MUSTs , but it seems to rely entirely on the definition of " malformed " which leads to H3GENERALPROTOCOL_ERROR . This is fine , but not especially helpful in isolating problems . Could we define an error code for this specific case ? 
 H2 just says malformed is treated as PROTOCOL_ERROR . So H3 is providing parity . There might be an argument for more fidelity but I 'm not convinced it would help much . It could require more contortions in the text - do you have different error for different types of malformed ? 
 Internally , we use a different error code . Of course , all internal error codes map to the same code for sending in RESETSTREAM / CONNECTIONCLOSE . 
 I 'm inclined not to do much , if anything , here . They all trace back to " malformed , " as you note , which leads to GENERALPROTOCOLERROR . The instances in which we use GPE are : Malformed HTTP messages  whose request headers change across multiple promises As a substitute for more specific codes I would n't be opposed to splitting the first two off into a new / two new codes , because that would be consistent with our principle of indicating the general area where the failure occurred . I would push back on having separate error codes for specific ways the message could be malformed , because that 's pretty expansive rabbit hole . 
 OK , I 'm satisfied with that response . I think that we 'll just have to signal extra information in the text field . Happy to close this . 
 do you think an error code for " malformed message " would be useful , if we do n't go into the various types of malformed ? 
 That might be useful , yes . 
 This is a design change , albeit a marginal one . 
 let 's merge the associated PR but keep this issue open and marked as " call - issued " 
 Keeping open , as requested . 
 Closing this now that the IESG review of draft 33 has concluded . 
 In fairness , I question whether the IESG review of the HTTP drafts has concluded . But as this is not an IESG comment , I 'm content to close it . People have had time to object . 
 Yes I agree  . This was due to me being over eager with the close button . The issue may not have strictly been raised in the period that the IESG were directed to review the doc , and they have yet to ballot on draft 33 . But either way there was no push back from the WG on this change since draft 33 was published .
Paragraph (version B):
the inclusion of invalid characters in field names or values.
Paragraph (version A):
Intermediaries that process HTTP requests or responses (i.e., any
intermediary not acting as a tunnel) MUST NOT forward a malformed
request or response.  Malformed requests or responses that are
detected MUST be treated as a stream error (errors) of type
H3_GENERAL_PROTOCOL_ERROR.
Paragraph (version B):
Intermediaries that process HTTP requests or responses (i.e., any
intermediary not acting as a tunnel) MUST NOT forward a malformed
request or response.  Malformed requests or responses that are
detected MUST be treated as a stream error (errors) of type
H3_MESSAGE_ERROR.
Paragraph (version B):
An HTTP message was malformed and cannot be processed.