Also, @metromoxie has implemented a pass at https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone …. We might still tweak the eviction rules, but secure now means secure.
@mikewest @metromoxie "it" = the new non-secure cookie? If so, I agree that's what should happen; It's not clear that that's what spec says.
-
-
@BRIAN_____: We agree on the expectation, so I'm happy to clarify in the spec. What would you like it to say?@metromoxie -
@mikewest@metromoxie Call out the case where eviction is triggered by insertion, noting the to-be-inserted cookie needs to be considered.
End of conversation
New conversation -
-
-
@mikewest@metromoxie In particular, I expect implementations will do:: while (not enough space) { evict a cookie } insert the new cookie -
@BRIAN_____: I'm 99% sure that's not the way Chrome works, as I just reviewed@metromoxie's patch. We insert, then garbage-collect. -
@mikewest@metromoxie Not questioning that. I'm just saying that the spec seems to currently allow the behavior I described. -
@BRIAN_____: I think it doesn't, but the only way to know that is to read all of the existing RFC, which is nuts. I'll clarify.@metromoxie -
@mikewest@metromoxie In the IETF anything not explicitly disallowed is allowed. Nothing disallows eviction before step 1 in RFC6265§5.3. -
@BRIAN_____: Uploading an -04 shortly that I hope clarifies the intent.@metromoxie
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.