Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Fearless HTTP requests abuse


Published on

Tech talk at 20o. GURU (Sao Paulo/Brazil Ruby User Group). November 26th, 2011

In REST architectures, there is always concerns about the high volume os HTTP requests, that can increase the load on servers. However, this issue could be easily solved if the system implement a good HTTP cache strategy. This talk will show in a simple way how works the underestimated HTTP cache protocol.

Published in: Technology
  • Login to see the comments

Fearless HTTP requests abuse

  1. 1. Fearless HTTP requests abuseLuís Cipriani@lfcipriani (twitter, linkedin, github, ...)20o. GURU (2011-11-26) - Sao Paulo/Brazil
  2. 2. ME
  3. 3. Motivation “REST implies doing SEVERAL HTTP requests, this is bad, doesn’t scale, blah blah blah...”
  4. 4. Motivation Shut UP! Don’t think like that! SEVERAL people already solved this problem SEVERAL ways.
  5. 5. Motivation One of the ways is HTTP cache
  6. 6. http cache BENEFITS • reduce bandwidth • reduce latency • reduce server load • hide network failures
  7. 7. http cache LOCALIZATION
  8. 8. http cache HEADERS 11 headers +15 directives
  9. 9. http cache FLOW 1. may I cache? 2. if it’s cached, is it fresh? 3. if stale, is it valid on server? 4. anything else I need to know? 11+15
  10. 10. http cache 1. POSSO CACHEAR? cache-control should revalidate, may I cache locally? may I cache anywhere? directive even being fresh? no-store no no n/a private yes no no no-cache yes yes yes public yes yes no 1. locally means a cache that servers only one consumer 2. these directives override any configuration of the cache 3. by default, we can cache non safe/authenticated requests, GET and HEAD and those with status code 200, 203, 206, 300, 301, 410 10 +11
  11. 11. http cache 2. IF IT IS CACHED, IS IT FRESH? the server should send the expiration time of an answer Expires: [RFC 1123 date] Cache-Control: max-age=600 but if the server didn’t do this, cache may assign heuristically the expiration time. 9 +10
  12. 12. http cache 2. IF IT IS CACHED, IS IT FRESH? Age calculation 7 +10
  13. 13. http cache 2. IF IT IS CACHED, IS IT FRESH? freshness_lifetime = Cache-Control: max-age | | Expires - Date response_is_fresh = freshness_lifetime > Age 7+7
  14. 14. http cache 3. IF STALE, REVALIDATE Validators Last-Modified ETag Conditionals If-Modified-Since If-None-Match if conditional request == false 304 Not Modified “... only return me a new resource if [conditional] applies on [validator] ...” 3+7
  15. 15. http cache 3.1. CONTROLLING REVALIDATION through client Cache-Control: no-cache + Pragma: no-cache Cache-Control: max-age=0 Cache-Control: only-if-cached 2+6
  16. 16. http cache 3.1. CONTROLLING REVALIDATION through origin server Cache-Control: must-revalidate after stale Cache-Control: proxy-revalidate Cache-Control: no-cache always 2+4
  17. 17. http cache 4. WHAT ELSE SHOULD I KNOW? Vary is part of cache key expired response, failed revalidation, Warning advanced age (more than 24 hours) don’t allow transformation Cache-Control: no-transform on the content Cache-Control: extensions for example, channels Cache-Control: stale-if-error availability over consistency Cache-Control: stale-while-revalidate background revalidation 0+0
  18. 18. http cache TIPS 1. use URLs consistently 2. common image library 3. use cache for pages that changes in low frequency 4. update cache with updated resources 5. don’t change files unnecessarily 6. use cookies only when necessary 7. minimize the use of SSL 8. validate your strategy on stolen from 0+0
  19. 19. http cache REFERÊNCIAS 1. 2. 3. 4. 5. 6. 0+0
  20. 20. Reformulação Box de Login Abril ID FIM