Entendendo o que é URI, URL, URN e conhecendo as diferenças entre POST e GET

Explanações sobre o que é URI, URL, URN e conferindo na prática algumas diferenças entre POST e GET com PHP e HTML. Também tem um teste que verifica algumas diferenças entre POST e GET, um teste simples dos limites de caracteres que alguns navegadores suportam na barra de endereços e um teste simples de velocidade das solicitações POST e GET.

[ Hits: 6.223 ]

Por: Buckminster em 30/04/2024


Execução dos Testes 2



3. Agora colocando POST no html e GET no php

Não repetirei todo o cabeçalho.

filter_has_var: INPUT_SERVER campo REQUEST_METHOD não corresponde
Array
(
...
    [REQUEST_URI] => /filtro/filtro.php
    [QUERY_STRING] =>
    [REQUEST_METHOD] => POST
...
)
var_dump(usuariopost)-não corresponde: string(5) "teste"
var_dump(usuarioget)-não corresponde: NULL

echo usuariopost-não corresponde: teste
echo usuarioget-não corresponde:

var_dump(usuariopost)-final: string(5) "teste"
var_dump(usuarioget)-final: NULL

print_r post: teste
print_r get:

Vejam que os dados não apareceram no URI (barra de endereços): http://localhost/filtro/filtro.php

Vejam que o [REQUEST_METHOD] => POST confirmou que o POST está funcionando, caso não estivesse apareceria GET no REQUEST_METHOD mesmo estando 'post' no html e 'get' no PHP.

Aliás, caso o POST não estivesse funcionando apareceria somente GET no REQUEST_METHOD em qualquer coisa que você colocasse tanto no HTML quanto no PHP, pois o GET é o método padrão.

Tem casos em que o PHP e o Apache estão em desacordo porque um está como módulo e o outro está como CGI/FASTCGI, etc, e daí se você colocar "AddType application/x-httpd-php .php" em vez de "AddHandler application/x-httpd-php .php" e/ou vice-versa no Apache pode acontecer de o método POST não funcionar e, nesse caso, as variáveis no PHP não receberão os valores vindos dos campos do HTML e ficarão como NULL.

4. Caso você mudar o parâmetro 'enable_post_data_reading' para Off no php.ini as variáveis $_POST e $_FILES virão sempre NULL, apesar de que o próprio php.ini diz que "It causes $_POST and $_FILES to always be empty;", ou seja, diz que sempre estarão vazias, porém, tem uma diferença entre variável vazia e variável NULL.

Como está no manual do PHP sobre a função empty():
"Determina se uma variável é considerada vazia. Uma variável é considerada vazia se não existir ou seu valor for igual a false. A função empty() não gera um aviso se a variável não existir."

"false" ou "true" são valores booleanos.

Não entrarei aqui na discussão sobre o conceito de "variável vazia" em programação.

NULL, segundo o Manual do PHP:
"O tipo null é o tipo unitário do PHP, ou seja, possui apenas um valor: null. Variáveis indefinidas e unset() resolverão para o valor null."

Colocando o parâmetro 'enable_post_data_reading' para Off no php.ini e reiniciando o Apache:

4.1. POST e POST

filter_has_var: INPUT_SERVER campo REQUEST_METHOD corresponde
Array
(
...
    [REQUEST_METHOD] => POST
    [QUERY_STRING] =>
    [REQUEST_URI] => /filtro/filtro.php
...
)
var_dump(usuariopost)-corresponde: NULL
var_dump(usuarioget)-corresponde: NULL

echo usuariopost-corresponde:
echo usuarioget-corresponde:

usuariopost-final: NULL
usuarioget-final: NULL

print_r post:
print_r get:

Vejam que as variáveis vieram como NULL no var_dump e "vazias" no echo e no print_r.

Então se deduz que, nesse caso, tecnicamente, não existe variável vazia no PHP (ou em qualquer linguagem, apesar de que não conheço todas), o que acontece é que dependendo da função o PHP retorna uma mensagem e em outras retorna nada, pois o HTML sempre e sempre enviará algum dado pelo GET e somente não enviará pelo GET quando o formulário for submetido com o "method" POST.

Não entrarei aqui na discussão sobre o conceito de "variável vazia" em programação.

Para quem quiser, no link https://www.php.net/manual/pt_BR/function.empty.php, tem um bom exemplo de comparação entre empty() e isset() para entender melhor essa lógica.

Tanto no PHP, como em qualquer linguagem, faz-se necessário ter um mínimo de conhecimento do retorno das funções, pois cada função tem um retorno específico de acordo com o que ela pretende e isso é definido pelos desenvolvedores da linguagem.

4.2. GET e GET com o parâmetro 'enable_post_data_reading' em Off no php.ini

filter_has_var: INPUT_SERVER campo REQUEST_METHOD corresponde
Array
(
...
    [REQUEST_METHOD] => GET
    [QUERY_STRING] => usuario=teste&senha=123&botao=
    [REQUEST_URI] => /filtro/filtro.php?usuario=teste&senha=123&botao=
...
)
var_dump(usuariopost)-corresponde: NULL
var_dump(usuarioget)-corresponde: string(5) "teste"

echo usuariopost-corresponde:
echo usuarioget-corresponde: teste

usuariopost-final: NULL
usuarioget-final: string(5) "teste"

print_r post:
print_r get: teste

As variáveis foram passadas pelo método padrão GET.

5. Agora colocando PUT (ou qualquer outro método que não GET ou POST) no html e no php

Independentemente se a opção 'enable_post_data_reading' estiver como On ou Off a saída será a mesma, pois o HTML enviará pelo GET.

Não repetirei todo o cabeçalho.

filter_has_var: INPUT_SERVER campo REQUEST_METHOD não corresponde
Array
(
...
    [REQUEST_METHOD] => GET
    [QUERY_STRING] => usuario=teste&senha=123&botao=
    [REQUEST_URI] => /filtro/filtro.php?usuario=teste&senha=123&botao=
...
)
var_dump(usuariopost)-não corresponde: NULL
var_dump(usuarioget)-não corresponde: string(5) "teste"

echo usuariopost não corresponde:
echo usuarioget não corresponde: teste

usuariopost-final: NULL
usuarioget-final: string(5) "teste"

print_r post:
print_r get: teste

O HTML suporta somente os métodos GET e POST, então os dados foram passados pelo padrão GET mesmo estando PUT no html e no php.

Como são códigos simples, o PHP, nesse caso, sempre mostrará no [REQUEST_METHOD] o que o HTML enviar (get ou post).

Fiz os testes no Linux como desktop e no Windows como desktop porque no servidor Linux o Apache e o PHP estão configurados com vários bloqueios/restrições e mais da metade dos parâmetros não aparecem, sendo que não quis alterar o arquivo. Porém, neste caso isso é determinado pelo navegador e pelas configurações do PHP e do servidor web (Apache, Nginx, etc), sendo que o sistema operacional em si não faz muita interferência neste caso.

Algumas restrições/bloqueios coloquei no parâmetro disable_functions e outras no disable_classes do php.ini e outras no apache2.conf.

Exemplo:

# Bloquear request method
RewriteCond %{REQUEST_METHOD} ^(connect|delete|head|options|patch|put|trace) [NC]
RewriteRule .* - [F]

Foram utilizados os navegadores Google Chrome, Edge, Firefox e Ópera e, neste caso, tiveram algumas diferenças no formato de saída e na ordem de apresentação dos parâmetros, mas não no conteúdo.

Quem quiser pode realizar mais testes e utilizar/aprimorar para estudos.

Página anterior     Próxima página

Páginas do artigo
   1. Entendendo o que é URI, URL, URN
   2. POST e GET
   3. Códigos dos Testes
   4. Execução dos Testes 1
   5. Execução dos Testes 2
   6. Código do Teste de Tempo
   7. Tempo de Solicitação 1
   8. Tempo de Solicitação 2
   9. Conclusão
Outros artigos deste autor

IPv6, DNSv6 e DHCPv6

Descritores de Arquivos e Swappiness

Atualizar o macOS no Mac - Opencore Legacy Patcher

Manual traduzido do Squid - Parte 2

Como ter o ChatGPT no seu site em PHP

Leitura recomendada

Migração de dados no Joomla

Gráficos em PHP Highcharts

Solução open source para clínicas médicas

Desenvolvendo um componente de calendário dinâmico em PHP

Debugando aplicações PHP usando phpdbg - parte 01

  
Comentários
[1] Comentário enviado por maurixnovatrento em 23/06/2024 - 23:35h

Excelente artigo e bem completo.

______________________________________________________________________
Inscreva-se no meu Canal: https://www.youtube.com/@LinuxDicasPro
Repositório GitHub do Canal: https://github.com/LinuxDicasPro
Grupo do Telegram: https://t.me/LinuxDicasPro
Meu GitHub Pessoal: https://github.com/mxnt10


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts