idnits 2.17.1 draft-pettersen-cache-context-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2616, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2616, updated by this document, for RFC5378 checks: 1997-10-16) -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 6, 2012) is 4433 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Pettersen 3 Internet-Draft Opera Software ASA 4 Updates: 2616 (if approved) March 6, 2012 5 Intended status: Standards Track 6 Expires: September 7, 2012 8 A context mechanism for controlling caching of HTTP responses 9 draft-pettersen-cache-context-06 11 Abstract 13 A common problem for sensitive web services is informing the client, 14 in a reliable fashion, when a password protected resource is no 15 longer valid because the user is logged out of the service. This is, 16 in particular, considered a potential security problem by some 17 sensitive services, such as online banking, when the user navigates 18 the client's history list, which is supposed to display the resource 19 as it was when it was loaded, not as it is the time the user 20 navigates to it. 22 This document presents a method for collecting such sensitive 23 resources into a group, called a "Cache Context", which permits the 24 server to invalidate all the resources belonging in the group either 25 by direct action, or according to some expiration policy. The 26 context can be configured to invalidate not just the resources, but 27 also specific cookies, HTTP authentication credentials and HTTP over 28 TLS session information. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in RFC 2119 [RFC2119]. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 7, 2012. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 83 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 84 2. How Cache Contexts work . . . . . . . . . . . . . . . . . . . 5 85 2.1. What is a Cache Context? . . . . . . . . . . . . . . . . . 5 86 2.2. Life of a Cache Context . . . . . . . . . . . . . . . . . 6 87 2.3. What happens when a context is discarded? . . . . . . . . 7 88 2.4. Server role . . . . . . . . . . . . . . . . . . . . . . . 7 89 2.5. Client role . . . . . . . . . . . . . . . . . . . . . . . 8 90 2.6. Effects on clients that do not support Cache Contexts . . 8 91 3. Context Specification Syntax . . . . . . . . . . . . . . . . . 8 92 3.1. ABNF syntax . . . . . . . . . . . . . . . . . . . . . . . 9 93 3.2. Context directive . . . . . . . . . . . . . . . . . . . . 9 94 3.3. Discard-Context directive . . . . . . . . . . . . . . . . 11 95 3.4. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 11 96 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 97 4.1. No expiration . . . . . . . . . . . . . . . . . . . . . . 11 98 4.2. With expiration . . . . . . . . . . . . . . . . . . . . . 12 99 4.3. With server-only cookie . . . . . . . . . . . . . . . . . 13 100 4.4. With cookiedomain . . . . . . . . . . . . . . . . . . . . 14 101 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 103 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 104 7.1. Informative References . . . . . . . . . . . . . . . . . . 16 105 7.2. Normative References . . . . . . . . . . . . . . . . . . . 16 106 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 17 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 109 1. Introduction 111 An early problem seen with HTTP was that, since it is inherently 112 stateless, there is no direct way to tell that two separate requests 113 are related, in particular that the requests originated from the same 114 user. While it is possible to encode the information in URLs or 115 queries, these methods are difficult to secure and it is also 116 difficult to maintain that information. 118 Finally, much of the problem was solved by the introduction of HTTP 119 Cookies [RFC6265] and the HTTP Authentication methods [RFC2617]. 121 One problem remains, though: History list navigation and access to 122 temporarily cached resources in web applications handling sensitive 123 data, such as online banking. The user may have logged out of the 124 service, or have been logged out automatically, and it is therefore 125 difficult for the client to tell whether to display a given resource, 126 not display it, or display it only after revalidating. 128 A typical use case will be that Alice goes to her online banking 129 site, checks her accounts, performs a couple of transactions and, 130 then, logs out of the bank. The bank might want to permit Alice to 131 navigate in her browser's history session while she is logged in, for 132 example, to recheck how much money is available in her account, but 133 prevent her from seeing any such information after she has logged 134 out. The reason is that, if she forgets to close her session (after 135 logging out) and then leaves her computer for a minute, Eve might 136 sneak over to peek at her colleague's account information by 137 navigating the history list in Alice's client. 139 Some providers of sensitive web services, for example banks, consider 140 failure to revalidate when displaying a cached document, or during 141 history navigation, a security problem. Some of these providers have 142 put great efforts into making sure the client is always revalidating 143 a page before displaying it, even while navigating history (which is 144 quite the opposite of what [RFC2616] sec. 13.13 recommends). This 145 has led to numerous strategies, such as the use of scripting and 146 using the "must-revalidate" Cache-Control directive as a revalidate 147 indication for history navigation. 149 Use of most of these methods not only results in more traffic to the 150 websites, but may also reduce the usability of the service. For 151 example, such methods may prevent a user from reviewing, or 152 correcting, data entered or presented earlier in the process, or to 153 print or save data presented earlier (for example, a receipt), 154 because the document is re-rendered differently. 156 While it is possible to use cookies and credential information to 157 group such documents, these methods are not fine-grained enough to 158 distinguish the sensitive parts of a site from the non-sensitive 159 parts. That kind of information is only available to the service 160 manager, and potentially the user, but not to the client. 162 This document presents a mechanism that permits a webservice to group 163 webpages by associating them in a named context, a "Cache Context", 164 that can have a specific expiration time or be specifically discarded 165 by the service. When a context is expired, or discarded, this 166 expires all documents that the client has that are part of the 167 context, meaning that they should either be deleted from the client's 168 cache or revalidated before being displayed to the user. 170 The mechanism is implemented as an extension to the HTTP Cache- 171 Control Header, but will also require access to state information 172 about HTTP Cookies and various forms of authentication credentials, 173 such as HTTP Authentication credentials and SSL Client Certificate 174 session states. 176 1.1. Terminology 178 HTTP Resource: A resource loaded from a HTTP [RFC2616] or HTTP over 179 TLS (HTTPS) [RFC2818] server 181 2. How Cache Contexts work 183 2.1. What is a Cache Context? 185 A Cache Context is a group of HTTP resources served from a specific 186 HTTP server, or group of HTTP servers, that are associated with a 187 name unique on that server, or within that group of servers. The 188 same name used from a different server, or a server that is not part 189 of the group, becomes a different context. Any given server can use 190 multiple contexts. 192 An HTTP resource from a server for which a context is defined does 193 not become part of the context unless the server explicitly informs 194 the client that it is a member of that context. 196 Such a group of resources may, for example, consist of all the 197 sensitive and password protected pages in a netbank web application, 198 but none of the images used when displaying the information. A 199 context may also just contain a group of temporary documents that are 200 not intended to be persistently cached. 202 A Cache Context can be created with policies that define when it is 203 to be discarded, and what actions it should then take, aside from 204 invalidating all the resources that are part of the context. Such 205 extra actions may include deleting or invalidating cookies, HTTP 206 authentication credentials or SSL session information. 208 2.2. Life of a Cache Context 210 The Cache Context enters existence the first time the server sends a 211 directive that informs the client about the context, and what 212 boundaries the context has. Resources are added to the context each 213 time the server sends a new resource with a directive specifying that 214 it is part of the context. 216 The server (or servers) that can serve resources in a context are 217 either the server defining the context (this is the default), or the 218 initial server can specify that the context spans the same group of 219 servers that will receive a specific HTTP cookie [RFC6265]. HTTP 220 cookies can be set by servers to only be returned by the client to 221 the server that sent them, or to be sent to all servers within the 222 domain which the sending server belongs to (there are some security 223 related restrictions to how extensive such domains can be). 225 For example, when Alice logs into her online bank, the server tells 226 her client that the "onlinebanking" context has been created, and, 227 for each successive action she makes to display her account 228 statements and filling in forms with payment information, the server 229 informs the client that the resulting pages are also part of the 230 "onlinebanking" context. 232 This continues until the context is discarded, an event that can come 233 about as a result of several conditions: 235 o Alice logs out of her online bank, and the server sends a "Discard 236 Context" notice to the client. 238 o The server has specified how long the context may live, and, when 239 the limit expires, the context is automatically discarded. 241 o The server can also tie the context to an HTTP State Management 242 cookie[RFC6265], and when this cookie expires, the context is also 243 automatically discarded. 245 o The client SHOULD offer the user the possibility to discard a 246 context in the form of a logout button. 248 o The client is shut down. 250 2.3. What happens when a context is discarded? 252 When a context is discarded, the resources that are part of the 253 context are deleted or marked for deletion (e.g., if they cannot be 254 deleted immediately due to internal book-keeping). When a resource 255 is marked for deletion, its status in the client's cache will be as 256 if it had been received with max-age set to 0 (zero); that is, it has 257 expired and cannot be displayed to the user unless its freshness has 258 been confirmed by the server after a validation request. This also 259 applies to such documents that would be displayed after the user 260 navigated in the browser's history. Preferably, the resource SHOULD 261 NOT be used if the client requests the same URI as that of the 262 resource, even conditionally, after the context has been discarded, 263 except during history list navigation. 265 If the context is associated with an HTTP cookie, discarding the 266 context also causes the client to automatically discard the cookie. 268 The server can also specify that when a context is discarded, stored 269 credentials that are valid for the server(s) that the context spans 270 should also be deleted. Such credentials should include, but should 271 not be limited to, HTTP Authentication credentials and SSL Session 272 information. Credentials stored in a client's password management 273 utility MUST NOT be discarded during this process. 275 Resources gathered in a context MUST NOT be kept persistently cached 276 by the client, but MUST be discarded when it shuts down, even if the 277 context is still valid. Please note that this does not prevent a 278 client from storing the resource on a disk drive for the duration. 279 If a server wants to prevent a resource from being stored on a disk 280 drive it MUST indicate this request with the "no-store" Cache-Control 281 directive. 283 A resource served with an explicit discard context instruction from 284 the server is not part of the context and MUST NOT be invalidated, 285 and the server SHOULD NOT include sensitive information in such 286 resources. 288 2.4. Server role 290 A service that wants to use Cache Contexts must update the HTTP 291 Cache-Control headers sent by each of the resources it wants to make 292 part of the context. Only the entry point(s) into the service will 293 need to send a directive with expiration details and other advanced 294 information, all other resources need only send a directive 295 specifying the name of the context. 297 When a service has exit points, such as a logout button, these 298 special resources should send a special directive informing 299 supporting clients that they must discard the context. 301 A server MAY send updated Cache Context directives to the client, and 302 need not resend unchanged attributes in such updates. 304 2.5. Client role 306 The client will parse the Cache-Control headers, and when it 307 recognizes the Cache Context directives it will take one of several 308 actions: 310 o Create the context as defined, if it does not already exist. 312 o If the server sends updated attributes for the context, update the 313 relevant attributes without changing other attributes. 315 o Add the resource to the context, unless the context is being 316 discarded as a result of the current directive. 318 o If the directive specifies that the context must be discarded 319 immediately, the client MUST proceed to invalidate all the 320 resources contained in the context, as specified above. 322 The client MUST maintain a list of active contexts for each server or 323 group of servers, their policies and which resources are associated 324 with them. 326 A server MAY specify that a resource belongs in two different 327 contexts by sending two directives in the same response. In such 328 cases the resource MUST be invalidated when the first context is 329 discarded. 331 2.6. Effects on clients that do not support Cache Contexts 333 All the information about the Cache Contexts and actions on them are 334 contained in new HTTP Cache-Control directives. Clients that do not 335 recognize these directives will ignore them. They will follow the 336 Cache-Control directives they recognize, and otherwise act as they 337 would if the Cache Contexts did not exist. 339 3. Context Specification Syntax 340 3.1. ABNF syntax 342 This ABNF has the same syntax as is used in [RFC2616], with the 343 addition of Incremental Alternatives from [RFC5234] section 3.3. 345 This syntax expands the cache-response-directive part of the Cache- 346 Control header ABNF in RFC 2616 sec. 14.9. 347 cache-response-directives =/ 348 "context" "=" context-name *[ ";" context-attributes] 349 | "discard-context" "=" context-name *[; context-name] 351 context-name = token 353 context-attributes = 354 "max-age" ":" delta-seconds 355 | "max-idle" ":" delta-seconds 356 | "cookie" ":" token 357 | "authenticated" 358 | "include-credentials" 359 | "no-persistent-history" 360 | extension-attributes 362 extension-attributes = token [":" token] 364 delta-seconds = 1*DIGIT 366 3.2. Context directive 368 The Context directive MUST be included with every response that is 369 included in a context. It always starts with a context-name, which 370 MUST be unique within the given service. 372 The context-name, which is case-insensitive, is the only required 373 field in the directive. All other attributes are optional, and need 374 only be specified when the attribute is updated. 376 By default, a given context on one server is not associated with a 377 context by the same name for another server, but if a group of 378 servers share a common HTTP cookie, they can participate in a common 379 context by using the same name. 381 Additionally, the directive may contain one or more context- 382 attributes that specify how the context as well as additional 383 information should be handled by the client. These attributes need 384 not be sent with every response, but when an attribute is sent with a 385 later response, it will update the context with the new information, 386 and any previous information for that attribute will be overwritten. 388 max-age This attribute indicates how many seconds the context should 389 be kept alive. A value of zero (0) means that the context should 390 be discarded immediately. A server may send this directive to 391 extend the lifetime of the context, e.g when the context nears the 392 end of its lifetime. If this attribute is not defined, the 393 context may live until the client is shut down, or a discard event 394 is received by the client. 396 max-idle This attribute indicates how many seconds the context 397 should be kept alive after the last time a resource in the context 398 was accessed. If this attribute is not defined, or the value is 399 zero (0), the context may live until the client is shut down, or a 400 discard event is received by the client. 402 cookie This attribute names the most specific HTTP State Management 403 Cookie [RFC6265] visible to the resource sending when this 404 attribute is received by the client. Cookies received and 405 accepted in the current response MAY be considered as part of 406 evaluating this attribute. The named cookie is used for three 407 purposes. First, its expiration date also becomes one of the 408 expiration dates of the context (an earlier max-age or max-idle 409 takes precedence), and if the server deletes the cookie, it 410 automatically deletes the context as well. Second, if a cookie is 411 valid across multiple hosts (that is, a domain), the given context 412 is also valid across the same hosts. Third, if the context 413 expires or is discarded before the cookie expires, the named 414 cookie MUST also be deleted when the context is discarded. 415 Multiple cookies may be defined by the server. By default, the 416 context is not assiciated with a cookie. 418 authenticated This attribute specifies that the context shall be 419 valid across the domain of the HTTP authentication credential 420 currently valid for the resource. The domain MUST at least 421 include the entire server, but multiple hosts may be included if 422 it is supported by the authentication mechanism, as for example 423 Digest Authentication [RFC2617] do. When the context is 424 discarded, the authentication credential is also discarded. If 425 the credential is invalidated or destroyed, the context must also 426 be discarded. By default, the context is not associated with an 427 authentication credential. 429 include-credentials This attribute informs the client that when this 430 context is discarded it MUST also destroy all HTTP Authorization 431 credentials, SSL/TLS Client Certificate authenticated sessions, 432 and other credentials that are valid for the resources that are 433 part of the context, thus logging the user out of the service. By 434 default, credentials are not included when discarding a context. 436 no-persistent-history This attribute informs the client that it 437 SHOULD NOT remember resources that are part of this context as 438 part of a persistent history mechanism. That is, the client 439 SHOULD maintain a history list in the document window or "tab" 440 viewed by the user (as described in [RFC2616] Section 13.13) , but 441 it SHOULD NOT keep any information about the URLs visited for a 442 persistent browsing history. By default, the client MAY remember 443 the used resources as part of a persistent history mechanism. 445 delta-seconds All periods used in the Cache Context attributes are 446 measured in seconds. 448 3.3. Discard-Context directive 450 A server can send this directive when it wants the client to 451 immediately discard the named context(s) (which includes the extra 452 actions specified in Section 2.3 when specified for the context). 454 Multiple context names separated by ";" can be specified in a single 455 directive, or multiple directives can be used. 457 3.4. Extensions 459 Extension attribute names SHOULD be documented in an RFC. 461 4. Examples 463 4.1. No expiration 464 Request-URI: http://www.example.com/initial_page 466 Response: 467 Cache-Control: context=simplecontext 469 Request-URI: http://www.example.com/page2 471 Response: 472 Cache-Control: context=simplecontext 474 Request-URI: http://www.example.com/page3 476 Response: 477 Cache-Control: context=simplecontext 479 Request-URI: http://www.example.com/page4 481 Response: 482 Cache-Control: max-age=3600 484 Request-URI: http://www.example.com/final_page 486 Response: 487 Cache-Control: discard-context=simplecontext 489 This example loads 3 resources, "initial_page", "page2" and "page3", 490 as part of the Cache Context "simplecontext". By default, this 491 context lives until the client is shut down. In this case, however, 492 the context is discarded by the response to the request for 493 "final_page". After the context has been discarded, all future 494 attempts to view "initial_page", "page2" or "page3" will result in an 495 "If-Modified-Since" validation request to the server, or a completely 496 new request, because the responses are no longer valid. 498 "Page4" is not part of the context, and is not discarded by the 499 "final_page" action, and no "If-Modified-Since" request will be sent 500 for this resource until 3600 seconds (1 hour) after it was originally 501 loaded. 503 4.2. With expiration 504 Request-URI: http://www.example.com/initial_page 506 Response: 507 Cache-Control: context=expirecontext;max-age=900 509 Request-URI: http://www.example.com/page2 511 Response: 512 Cache-Control: context=expirecontext 514 Request-URI: http://www.example.com/page3 516 Response: 517 Cache-Control: context=expirecontext 519 This example loads 3 resources, "initial_page", "page2" and "page3", 520 as part of the Cache Context "expirecontext". By default, this 521 context lives for at most 15 minutes (900 seconds). After the 522 context has been discarded (in this case, after 15 minutes), all 523 future attempts to view "initial_page", "page2" or "page3" will 524 result in an "If-Modified-Since" validation request to the server, or 525 a completely new request, because the responses are no longer valid. 527 4.3. With server-only cookie 528 Defined cookie (server only): 529 ExampleSession=UserId; max-age=900; domain=www.example.com 531 Request-URI: http://www.example.com/initial_page 533 Response: 534 Cache-Control: context=cookiecontext;cookie=ExampleSession 536 Request-URI: http://www.example.com/page2 538 Response: 539 Cache-Control: context=cookiecontext 541 Request-URI: http://www.example.com/page3 543 Response: 544 Cache-Control: context=cookiecontext 546 Request-URI: http://www.example.com/final_page 548 Response: 549 Cache-Control: discard-context=cookiecontext 551 This example loads 3 resources, "initial_page", "page2" and "page3", 552 as part of the Cache Context "cookiecontext" which is associated with 553 the cookie "ExampleSession". By default, this context lives until 554 the cookie expires 15 minutes (900 seconds) after it was set. In 555 this case, however, the context is discarded by the response to the 556 request for "final_page". After the context has been discarded, the 557 cookie "ExampleSession" no longer exists even if it was not yet 558 expired, and all future attempts to view "initial_page", "page2" or 559 "page3" will result in an "If-Modified-Since" validation request to 560 the server, or a completely new request, because the responses are no 561 longer valid. 563 4.4. With cookiedomain 564 Defined cookie: 565 ExampleDomainSession=UserId; max-age=900; domain=.example.com 567 Request-URI: http://www.example.com/initial_page 569 Response: 570 Cache-Control: context=domaincontext;cookie=ExampleSession 572 Request-URI: http://server2.example.com/page2 574 Response: 575 Cache-Control: context=domaincontext 577 Request-URI: http://server3.example.com/page3 579 Response: 580 Cache-Control: context=domaincontext 582 Request-URI: http://final.example.com/final_page 584 Response: 585 Cache-Control: discard-context=domaincontext 587 This example loads 3 resources, "initial_page", "page2" and "page3" 588 from different servers, as part of the Cache Context "domaincontext" 589 which is associated with the cookie "ExampleDomainSession" which is 590 sent to the entire example.com domain. This causes "domaincontext" 591 to apply to all servers in the example.com domain, too. By default, 592 this context lives until the cookie expires 15 minutes (900 seconds) 593 after it was set. In this case, however, the context is discarded by 594 the response to the request for "final_page". After the context has 595 been discarded, the cookie "ExampleDomainSession" no longer exists 596 even if it was not yet expired, and all future attempts to view 597 "initial_page", "page2" or "page3" will result in an "If-Modified- 598 Since" validation request to the server, or a completely new request, 599 because the responses are no longer valid. 601 5. IANA Considerations 603 This document makes no request of IANA. 605 Note to RFC Editor: this section may be removed on publication as an 606 RFC. 608 6. Security Considerations 610 If two independent web applications that use the same name for their 611 contexts are hosted on the same server, or within the domain covered 612 by one or both of the contexts, they are likely to interfere with 613 each other. This can happen if the user uses both applications while 614 both contexts are valid, possibly causing some loss of functionality 615 and information if a context is discarded, or prolonged exposure of 616 information if the session is extended. Such interference can only 617 be avoided by choosing context names that are not shared among 618 independent web applications. 620 When using the Cookie attribute, which expands the context to a 621 cookie's domain, this specification relies on the same security 622 safeguards that are used by the client when accepting the cookie in 623 order to avoid interfering with web applications in other services 624 that are using the same context name. Given the wide variety of 625 domain name hierarchies used by TLD administrators, it is presently 626 possible, unless prevented by client specific heuristics, for a 627 server to share a cookie with all servers within a registry-like part 628 of a TLD, such as the "co.uk" Domain Name hierarchy. This kind of 629 interference may also occur within smaller domain name segments. 631 A possible method to avoid or limit such interference could be to 632 require clients to perform an evaluation of the context directive's 633 cookie specification from the resource's environment, which might 634 associate it with a different cookie. Such an evaluation would most 635 likely result in undesirable processing overhead, and is therefore 636 not included in this specification. 638 7. References 640 7.1. Informative References 642 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 644 7.2. Normative References 646 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 647 Requirement Levels", BCP 14, RFC 2119, March 1997. 649 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 650 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 651 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 653 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 654 Leach, P., Luotonen, A., and L. Stewart, "HTTP 655 Authentication: Basic and Digest Access Authentication", 656 RFC 2617, June 1999. 658 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 659 Specifications: ABNF", STD 68, RFC 5234, January 2008. 661 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 662 April 2011. 664 Appendix A. Open Issues 666 Should the client indicate support for Cache Contexts? Is it 667 necessary to do so? If so, how should support be indicated? A 668 possiblity is an HTTP header with a directive indicating support. 670 Should the client indicate that it has accepted a particular context 671 and is using it? If so, how should it indicate it? Possible 672 solution: The above mentioned header directive could contain a list 673 of active contexts. 675 Should the client, when automatically discarding a context, replace 676 the viewed document with a "you have been logged out of the service" 677 document? Or should the last viewed page continue to be displayed? 678 If the document is replaced, how should this situation be handled 679 when a server specifies an unreasonably short expiration time? 681 How should a client interpret non-context Cache-Control directives in 682 the same header? Given that such directives are likely intended to 683 place more restrictive non-context expiration policies on the 684 resource than is necessary for clients that do support Cache 685 Contexts, the best solution may be that clients supporting Cache 686 Contexts should ignore at least the "no-cache", "max-age=0" and 687 "must-revalidate" directives for resources that are part of a 688 context, all of which are implied when the cache-context is 689 discarded. 691 How should responses to requests using methods that have side 692 effects, such as POST, be handled after a context has been discarded? 693 Such responses should most likely not be revalidated automatically. 694 The best option may be to require the client to replace the resource 695 with an information message about the resource not being available 696 anymore. 698 Author's Address 700 Yngve N. Pettersen 701 Opera Software ASA 702 Waldemar Thranes gate 98 703 N-0175 OSLO, 704 Norway 706 Email: yngve@opera.com