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.
Parte 5: 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]
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.
______________________________________________________________________
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