tests layout readme

This commit is contained in:
hugogogo
2022-07-29 15:29:09 +02:00
parent 7e5492b793
commit c821d3d92d

106
README.md
View File

@@ -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
```