tests layout readme
This commit is contained in:
106
README.md
106
README.md
@@ -327,7 +327,7 @@ Learn more about CORS here.
|
|||||||
- X-Powered-By : May be set by hosting environments or other frameworks and contains information about them while not providing any usefulness to the application or its visitors. Unset this header to avoid exposing potential vulnerabilities.
|
- X-Powered-By : May be set by hosting environments or other frameworks and contains information about them while not providing any usefulness to the application or its visitors. Unset this header to avoid exposing potential vulnerabilities.
|
||||||
- X-XSS-Protection : Enables cross-site scripting filtering.
|
- X-XSS-Protection : Enables cross-site scripting filtering.
|
||||||
|
|
||||||
#### Fetch metadata request headers
|
#### FETCH METADATA REQUEST HEADERS
|
||||||
|
|
||||||
Fetch metadata request headers provides information about the context from which the request originated. This allows a server to make decisions about whether a request should be allowed based on where the request came from and how the resource will be used.
|
Fetch metadata request headers provides information about the context from which the request originated. This allows a server to make decisions about whether a request should be allowed based on where the request came from and how the resource will be used.
|
||||||
|
|
||||||
@@ -370,18 +370,18 @@ Fetch metadata request headers provides information about the context from which
|
|||||||
- **Link** : The Link entity-header field provides a means for serializing one or more links in HTTP headers. It is semantically equivalent to the HTML <link> element.
|
- **Link** : The Link entity-header field provides a means for serializing one or more links in HTTP headers. It is semantically equivalent to the HTML <link> element.
|
||||||
- *Push-Policy* Experimental : A Push-Policy defines the server behavior regarding push when processing a request.
|
- *Push-Policy* Experimental : A Push-Policy defines the server behavior regarding push when processing a request.
|
||||||
- **Retry-After** : Indicates how long the user agent should wait before making a follow-up request.
|
- **Retry-After** : Indicates how long the user agent should wait before making a follow-up request.
|
||||||
- *Signature* Experimental : The Signature header field conveys a list of signatures for an exchange, each one accompanied by information about how to determine the authority of and refresh that signature.
|
- **Signature** Experimental : The Signature header field conveys a list of signatures for an exchange, each one accompanied by information about how to determine the authority of and refresh that signature.
|
||||||
- *Signed-Headers* Experimental : The Signed-Headers header field identifies an ordered list of response header fields to include in a signature.
|
- **--Signed-Headers** (Experimental) : The Signed-Headers header field identifies an ordered list of response header fields to include in a signature.
|
||||||
- **Server-Timing** : Communicates one or more metrics and descriptions for the given request-response cycle.
|
- **Server-Timing** : Communicates one or more metrics and descriptions for the given request-response cycle.
|
||||||
- **Service-Worker-Allowed** : Used to remove the path restriction by including this header in the response of the Service Worker script.
|
- **Service-Worker-Allowed** : Used to remove the path restriction by including this header in the response of the Service Worker script.
|
||||||
- **SourceMap** : Links generated code to a source map.
|
- **SourceMap** : Links generated code to a source map.
|
||||||
- **Upgrade** : The relevant RFC document for the Upgrade header field is RFC 7230, section 6.7. The standard establishes rules for upgrading or changing to a different protocol on the current client, server, transport protocol connection. For example, this header standard allows a client to change from HTTP 1.1 to HTTP 2.0, assuming the server decides to acknowledge and implement the Upgrade header field. Neither party is required to accept the terms specified in the Upgrade header field. It can be used in both client and server headers. If the Upgrade header field is specified, then the sender MUST also send the Connection header field with the upgrade option specified. For details on the Connection header field please see section 6.1 of the aforementioned RFC.
|
- **Upgrade** : The relevant RFC document for the Upgrade header field is RFC 7230, section 6.7. The standard establishes rules for upgrading or changing to a different protocol on the current client, server, transport protocol connection. For example, this header standard allows a client to change from HTTP 1.1 to HTTP 2.0, assuming the server decides to acknowledge and implement the Upgrade header field. Neither party is required to accept the terms specified in the Upgrade header field. It can be used in both client and server headers. If the Upgrade header field is specified, then the sender MUST also send the Connection header field with the upgrade option specified. For details on the Connection header field please see section 6.1 of the aforementioned RFC.
|
||||||
- **X-DNS-Prefetch-Control** : Controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.
|
- **X-DNS-Prefetch-Control** : Controls DNS prefetching, a feature by which browsers proactively perform domain name resolution on both links that the user may choose to follow as well as URLs for items referenced by the document, including images, CSS, JavaScript, and so forth.
|
||||||
- **(X-Firefox-Spdy)** Deprecated Non-Standard : TBD
|
- **-- X-Firefox-Spdy** (Deprecated Non-Standard) : TBD
|
||||||
- **(X-Pingback)** (Non-Standard) : TBD
|
- **-- X-Pingback** (Non-Standard) : TBD
|
||||||
- **X-Requested-With** : TBD
|
- **X-Requested-With** : TBD
|
||||||
- **(X-Robots-Tag)** (Non-Standard) : The X-Robots-Tag HTTP header is used to indicate how a web page is to be indexed within public search engine results. The header is effectively equivalent to <meta name="robots" content="…">.
|
- **-- X-Robots-Tag** (Non-Standard) : The X-Robots-Tag HTTP header is used to indicate how a web page is to be indexed within public search engine results. The header is effectively equivalent to <meta name="robots" content="…">.
|
||||||
- **(X-UA-Compatible)** (Non-Standard) : Used by Internet Explorer to signal which document mode to use.
|
- **-- X-UA-Compatible** (Non-Standard) : Used by Internet Explorer to signal which document mode to use.
|
||||||
|
|
||||||
|
|
||||||
---
|
---
|
||||||
@@ -393,95 +393,5 @@ Fetch metadata request headers provides information about the context from which
|
|||||||
- [bind() vs connect()](https://stackoverflow.com/questions/27014955/socket-connect-vs-bind)
|
- [bind() vs connect()](https://stackoverflow.com/questions/27014955/socket-connect-vs-bind)
|
||||||
- [INADDR_ANY for bind](https://stackoverflow.com/questions/16508685/understanding-inaddr-any-for-socket-programming)
|
- [INADDR_ANY for bind](https://stackoverflow.com/questions/16508685/understanding-inaddr-any-for-socket-programming)
|
||||||
- [hack with CGI](https://www.youtube.com/watch?v=ph6-AKByBU4)
|
- [hack with CGI](https://www.youtube.com/watch?v=ph6-AKByBU4)
|
||||||
---
|
- [http headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)
|
||||||
## code architecture
|
|
||||||
|
|
||||||
|
|
||||||
```
|
|
||||||
functions action in this scenario :
|
|
||||||
______
|
|
||||||
sd = SOCKET() : create a listening socket descriptor
|
|
||||||
__________
|
|
||||||
SETSOCKOPT(sd) : allow socket descriptor to be reuseable
|
|
||||||
_____
|
|
||||||
IOCTL(sd) : set listening socket and all incoming socket to be non-blocking
|
|
||||||
_____
|
|
||||||
FCNTL(sd) : set listening socket and all incoming socket to be non-blocking
|
|
||||||
____
|
|
||||||
BIND(port) : associate listening socket to a port
|
|
||||||
______
|
|
||||||
LISTEN(nb_queue) : queue the incoming connections to listening socket
|
|
||||||
up to a chosen number
|
|
||||||
____
|
|
||||||
POLL(fds[]) : wait for event on files descriptors
|
|
||||||
______
|
|
||||||
SELECT(fds[]) : wait for event on files descriptors
|
|
||||||
FD_SET() : add a fd to a set
|
|
||||||
FD_CLR() : remove a fd from a set
|
|
||||||
FD_ZERO() : clears a set
|
|
||||||
FD_ISSET() : test to see if a fd is part of the set
|
|
||||||
______
|
|
||||||
new_sd = ACCEPT() : extract first connection request in queue of listening socket
|
|
||||||
and creates a new socket that is connected
|
|
||||||
____
|
|
||||||
RECV(new_sd) : read data in socket created by accept()
|
|
||||||
____
|
|
||||||
SEND(new_sd) : write data in socket created by accept()
|
|
||||||
_____
|
|
||||||
CLOSE(new_sd) : close open file (here socket) descriptor
|
|
||||||
|
|
||||||
```
|
|
||||||
|
|
||||||
compare architectures :
|
|
||||||
|
|
||||||
```
|
|
||||||
POLL SELECT
|
|
||||||
______ ______ ______
|
|
||||||
lstn_sd = SOCKET() | lstn_sd = SOCKET() | lstn_sd = SOCKET()
|
|
||||||
| __________ | __________
|
|
||||||
| SETSOCKOPT() | SETSOCKOPT()
|
|
||||||
| _____ | _____
|
|
||||||
| IOCTL() | IOCTL()
|
|
||||||
____ | ____ | ____
|
|
||||||
BIND(port) | BIND(port) | BIND(port)
|
|
||||||
______ | ______ | ______
|
|
||||||
LISTEN(nb_queue) | LISTEN(nb_queue) | LISTEN(nb_queue)
|
|
||||||
| |
|
|
||||||
| fds[1] = lstn_sd | FD_SET(lstn_fd)
|
|
||||||
| |
|
|
||||||
| | max_sd = lstn_sd
|
|
||||||
| |
|
|
||||||
loop | loop | loop
|
|
||||||
. ____ | . ____ | . ______
|
|
||||||
. POLL() | . POLL(fds[]) | . SELECT(fds[])
|
|
||||||
. | . | .
|
|
||||||
. | . loop through fds[] | . loop i++ < max_fd
|
|
||||||
. | . . | . .
|
|
||||||
. | . . POLLIN && lstn_sd ? | . . FD_ISSET(i) & lstn_fd ?
|
|
||||||
. | . . loop | . . loop
|
|
||||||
. ______ | . . . ______ | . . . ______
|
|
||||||
. ACCEPT() | . . . new_sd = ACCEPT() | . . . new_sd = ACCEPT()
|
|
||||||
. | . . . | . . .
|
|
||||||
. | . . . fds[] += new_sd | . . . FD_SET new_sd in fds[]
|
|
||||||
. | . . | . . .
|
|
||||||
. | . . | . . . max_sd = new_sd
|
|
||||||
. | . . | . .
|
|
||||||
. | . . or POLLIN ? | . . or FD_ISSET ?
|
|
||||||
. | . . loop | . . loop
|
|
||||||
. ____ | . . . ____ | . . . ____
|
|
||||||
. RECV() | . . . RECV() | . . . RECV()
|
|
||||||
. ____ | . . . ____ | . . . ____
|
|
||||||
. SEND() | . . . SEND() | . . . SEND()
|
|
||||||
. | |
|
|
||||||
. | loop through fds[] | loop through fds[]
|
|
||||||
. _____ | . _____ | . _____
|
|
||||||
. CLOSE(fds[]) | . CLOSE(fds[]) | . CLOSE(fds[])
|
|
||||||
|
|
||||||
|
|
||||||
first, create the socket, add some options, bind it, and listen to it.
|
|
||||||
then, do a loop starting with POLL or SELECT
|
|
||||||
if it's incomming connexions, accept and add them all to the list
|
|
||||||
if it's accepted connexions, read their datas and write new datas
|
|
||||||
|
|
||||||
```
|
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user