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: 3.717 ]

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

Manual do IPtables - Comentários e sugestões de regras

kernel Linux otimizado - Compilação e teste

Compilando kernel no Debian Squeeze

Compilação do Kernel

Instalação do PAP (PostgreSL, Apache2 e PHP7) no Debian Jessie

Leitura recomendada

Criando um blog com o CakePHP 2.2.1

Requisições assíncronas em PHP usando AJAX - Parte I

Migração de dados no Joomla

A simples classe Date Operations

Debian com Apache, PHP4, PHP5 e MySQL

  
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