Notite HTTP

--------------------------------------------------------------------------------------------------------------------HTTP Cookies
HTTP cookie is a small piece of data sent from a website and stored in a user's web browser
while the user is browsing that website. Every time the user loads the website, the browser
sends the cookie back to the server to notify the website of the user's previous activity.[1]
Cookies were designed to be a reliable mechanism for websites to remember
statefulinformation (such as items in a shopping cart) or to record the user's browsing activity
Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
Cookie: value1; value2; name1=value1
Set-Cookie: name=Nicholas; expires=Sat, 02 May 2009 23:38:25 GMT
Set-Cookie: name=Nicholas; domain=nczonline.net
Set-Cookie: name=Nicholas; path=/blog
Set-Cookie: name=Nicholas; secure
Suprascriere:
Set-Cookie: name=Nicholas; domain=nczonline.net; path=/blog
Set-Cookie: name=Greg; domain=nczonline.net; path=/blog
+++Set-Cookie: name=Nicholas; domain=nczonline.net; path=/
care e complet diferit de celelalte doua -> nu le suprascrie
Data viitoare cand se trimite un request -> doua cookie-uri vor functiona pe acelasi path.
Cookie: name=Greg; name=Nicholas
The maximum size for all cookies sent to the server has remained the same since the original
cookie specification: 4 KB. Anything over that limit is truncated and wont be sent to the server
SubCookies -> Se pot memora intr-un singur field de cookie mai multe combinatii de nume si
valoare pentru a creste capacitatea de stocare .
name=a=b&c=d&e=f&g=h
Microsoft introduced a new option for cookies in Internet explorer 6 SP1: HTTP-only cookies.
The idea behind HTTP-only cookies is to instruct a browser that a cookie should never be
accessible via JavaScript through the document.cookie property
Set-Cookie: name=Nicholas; HttpOnly

Session cookie[edit]
A session cookie, also known as an in-memory cookie or transient cookie, exists only in
temporary memory while the user navigates the website.[15] When an expiry date or validity
interval is not set at cookie creation time, a session cookie is created. Web browsers normally
delete session cookies when the user closes the browser.[16][17]

Persistent cookie[edit]
A persistent cookie outlasts user sessions.[15] If a persistent cookie has its Max-Age set to one
year (for example), then, during that year, the initial value set in that cookie would be sent back
to the server every time the user visited the server. This could be used to record a vital piece of
information such as how the user initially came to this website. For this reason, persistent
cookies are often used as tracking cookies.

Secure cookie[edit]
A secure cookie has the secure attribute enabled and is only used via HTTPS, ensuring that the
cookie is always encrypted when transmitting from client to server. This makes the cookie less
likely to be exposed to cookie theft via eavesdropping. In addition to that, all cookies are subject
to browser's same-origin policy.[18]

HttpOnly cookie[edit]
The HttpOnly attribute is supported by most modern browsers.[19][20] On a supported browser, an
HttpOnly session cookie will be used only when transmitting HTTP (or HTTPS) requests, thus
restricting access from other, non-HTTP APIs such as JavaScript. This restriction mitigates but
does not eliminate the threat of session cookie theft via cross-site scripting (XSS).[21] This
feature applies only to session-management cookies, and not other browser cookies.
--------------------------------------------------------------------------------------------------------------------X-Forwarded-For
The X-Forwarded-For (XFF) HTTP header field is a de facto standard for identifying the
originating IP address of a client connecting to a web server through an HTTP proxy or load
balancer. This is an HTTP request header which was introduced by the Squid caching proxy
server's developers. A standard has been proposed at the Internet Engineering Task Force
(IETF) for standardizing the Forwarded HTTP header.[1]
X-Forwarded-For: client, proxy1, proxy2
--------------------------------------------------------------------------------------------------------------------HTTP Cache
- HTTP caching only works for "safe" HTTP methods (like GET and HEAD).
- IMPORTANT -> In practice, most caches do nothing when requests have a
cookie, an authorization header, use a non-safe method (i.e. PUT, POST, DELETE), or
when responses have a redirect status code.
HTTP specifies four response cache headers that are looked at here:

Cache-Control
Expires
ETag
Last-Modified

Cache Controls.
1.PUBLIC- PRIVATE
public - Indicates that the response may be cached by both private and shared caches.
private - Indicates that all or part of the response message is intended for a single user and
must not be cached by a shared cache.
2. EXPIRATION
MAX-AGE - > Specify the max age validity for cached content - used to consider data to be
staled. Works just like using Expire tag in HTTP REsponse. Can also be s-maxage - taken into
acount only for shared caches.
Expires - > According to the HTTP specification, "the Expires header field gives the date/time
after which the response is considered stale. EX: Expires: Thu, 01 Mar 2011 16:00:00 GMT.
Note that in HTTP versions before 1.1 the origin server wasn't required to send the Date header.
Consequently, the cache (e.g. the browser) might need to rely on the local clock to evaluate the
Expires header making the lifetime calculation vulnerable to clock skew. Another limitation of the
Expires header is that the specification states that "HTTP/1.1 servers should not send Expires
dates more than one year in the future."
3.VALIDATION
Validation with ETAG -> The ETag header is a string header (called the "entity-tag") that
uniquely identifies one representation of the target resource. It's entirely generated and set by
your application so that you can tell, for example, if the/about resource that's stored by the
cache is up-to-date with what your application would return. An ETag is like a fingerprint and is
used to quickly compare if two different versions of a resource are equivalent. Like fingerprints,
each ETag must be unique across all representations of the same resource.
Last-Modified -> The Last-Modified header is the second form of validation. According to the
HTTP specification, "TheLast-Modified header field indicates the date and time at which the
origin server believes the representation was last modified." In other words, the application
decides whether or not the cached content has been updated based on whether or not it's been
updated since the response was cached.
4. VARYING THE RESPONSE
If two people request the same URI of a cacheable resource, the second person will receive the
cached version. Sometimes this isn't enough and different versions of the same URI need to be
cached based on one or more request header values
Vary: Accept-Encoding, User-Agent

5. NO CACHE- NO STORE
no-cache indicates that the returned response cannot be used to satisfy a subsequent request
to the same URL without first checking with the server if the response has changed. As a result,
if a proper validation token (ETag) is present, no-cache will incur a roundtrip to validate the
cached response
By contrast, no-store is much simpler, as it simply disallows the browser and all intermediate
caches to store any version of the returned response
6. CACHING DEFAULTS
If no cache header is defined (Cache-Control, Expires, ETag or Last-Modified),
Cache-Control is set to no-cache, meaning that the response will not be cached;
If Cache-Control is empty (but one of the other cache headers is present), its
value is set to private, must-revalidate;
But if at least one Cache-Control directive is set, and no public or private
directives have been explicitly added, Symfony adds the private directive automatically
(except when s-maxage is set).