Multiple edits (per the interim) #132
Conversation
Remove unused settings.
Specifically calls them out as connection errors of type PROTOCOL_ERROR.
Per the interim.. dealing with frame size limits
Move definition of FINAL flag to DATA and HEADERS frames. Replace HEADERS+PRIORITY with HEADERS and a separate PRIORITY flag. Renumber other associated flags now that FINAL is frame-specific. Add a MSG_DONE flag for future extensibility.
| or if the size exceeds a strictly defined limit, the endpoint MUST | ||
| send a FRAME_TOO_LARGE error. If the frame stream identifier is 0x0, | ||
| this code MUST be sent as a connection error. If the stream | ||
| identifier is anything other than 0x0, it is sent as stream error. |
There was a problem hiding this comment.
If this is going to be so verbose, then you need to include the fact that HEADERS and PUSH_PROMISE also require that the connection be broken.
|
Can you try this one again? I think that you didn't properly rebase your checked out copy before making changes. This would be a hard commit to track. |
|
@jpinner Yes, I know, we need to fully address the On or About issue before that would make much sense tho. This is an incremental change... We still need to figure out the more extensive edits. @martinthomson I'm trying to figure out the best way to handle these edits. They are very extensive at this point, and it's only going to get more complex before we're done, especially with multiple people submitting overlapping pull requests... |
Clear(er) explanation about associated streams with PUSH_PROMISE.. clear examples showing the use of RST_STREAM and PRIORITY with and without ASSOCIATED_ONLY set.
|
I definitely want to see a separate commit for the ASSOCIATED flags on PRIORITY and RST_STREAM. There are other items here as well that make it hard to review this change set. |
Assign the default priority 2^30-1 as agreed to at the interim
|
Yes, these changes are going to be quite extensive. Given the time constraints, I'm going to keep working in my branch on these edits, tho. Once they're done, I'll come up with a better approach to attempt an incremental review. |
|
"Per the interim... address frame size limits. 64k in the general case, 16k in HTTP. individual frame types and usage can impose additional limits." Please update to explain this in detail. I know we agreed on this in the interim meeting, but I'd like the full explanation documented in writing for posterity. |
There are quite a few edits in here... merges from the other outstanding pull requests included... It was easier just to merge these and work on them iteratively given the extensive changes...