# Adicionando HTML

Na última seção construímos a primeira versão do nosso simples HTTP server, que envia uma mensagem `PONG` em plain text. 

Mas como estamos falando de Web, seria mais adequado enviarmos HTML no body, não? 

Vamos modificar o server para responder um **content-type header** `text/html`, indicando que o client deve saber *renderizar HTML*, bem como fazendo com que o body seja um **parágrafo** HTML, no caso colocando a palavra **PONG** dentro da HTML tag `<p>`.

```bash
## Server
$ echo -e "HTTP/1.1 200\r\n\
Content-Type: text/html\r\n\
\r\n\
<p>PONG</p>" | nc -lvN 8080

Listening on 0.0.0.0 8080
```

Do lado do client, não precisamos mais de body. Podemos, por exemplo, indicar que queremos uma rota/caminho para o recurso `/ping`, deixando assim nossa comunicação HTTP mais semântica.&#x20;

```bash
## Client
$ echo -e "GET /ping HTTP/1.1\r\n\
Content-Type: text/html\r\n\
\r\n" | nc -v localhost 8080

HTTP/1.1 200
Content-Type: text/html

<p>Hello</p>
```

Podemos ver que, apesar do HTTP header indicar que o tipo do conteúdo é HTML, o comando `netcat` do lado do client não sabe renderizar.&#x20;

Isto porque, para renderizar HTML, é preciso ter um motor de renderização, coisa que os Web browsers implementam. Vamos experimentar outros HTTP clients.

### Outros HTTP clients

Vamos começar com `curl`, que é um HTTP client muito utilizado para testes e automação na linha de comando do terminal:

```bash
## Client
$ curl localhost:8080/ping
<p>Hello</p>
```

Interessante. Podemos ver que o programa `curl` sabe **interpretar uma mensagem HTTP**, mas *não sabe renderizar HTML* pois não é um Web browser.

Então é hora de testar no **browser**.

<figure><img src="/files/cAskzwwsFw8ZVJ26Blu1" alt=""><figcaption></figcaption></figure>

**Super** **Yay**! Por isto é chamado de **Web browser**, correto? Vamos também olhar o request que o browser mandou para o server:

```
GET / HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8
Sec-GPC: 1
Accept-Language: en-GB,en
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
```

Podemos reparar que a mensagem HTTP request tem o mesmo padrão que estávamos utilizando, com a diferença que o web browser adiciona muito mais HTTP headers para um melhor controle entre client e server.

Basta um web server saber ler e lidar com tais HTTP headers, enviar outros headers relevantes de volta no response e pronto, temos uma melhor experiência de utilização para os usuários de websites, tudo contemplado no padrão HTTP!

### Estado da conexão no HTTP

Importante destacar que, até o momento, tudo o que temos visto foi uma mensagem caminhar do cliente para o servidor (request), outra mensagem caminhar do servidor para o client (response) e então o server terminar o processo.&#x20;

O quê está acontecendo com a conexão?

#### HTTP é stateless por padrão

Como HTTP se posiciona na camada de Aplicação do TCP/IP, a informação que cliente e servidor trocam está sendo transportada via TCP.&#x20;

Em cada comunicação request-response é criada uma nova conexão TCP. Com isso, quando um cliente faz um pedido HTTP qualquer ao servidor e este responde, a conexão é encerrada e não há qualquer estado HTTP entre diferentes conexões TCP.&#x20;

Podemos então resumir o fluxo:

1. Client inicia conexão TCP como server
2. Client envia um request HTTP através da conexão
3. Server recebe a mensagem, processa e envia uma resposta HTTP
4. Server encerra a conexão com o client

Entender este fluxo é importante para compreendermos as limitações do HTTP por ser **stateless** (sem estado). Em futuras seções, vamos explorar formas de mitigar esta limitação para que possamos simular uma característica *stateful* (com estado).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://web101.leandronsp.com/construindo-um-simples-echo-web-server/adicionando-html.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.