por que curl e wget resultariam em um 403 proibido?

Eu tento fazer download de um arquivo com wgete curle é rejeitada com um erro 403 (proibido).

Eu posso ver o arquivo usando o navegador da web na mesma máquina.

Tento novamente com o agente de usuário do meu navegador, obtido por http://www.whatsmyuseragent.com . Eu faço isso:

wget -U 'Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0' http://...

e

curl -A 'Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0' http://...

mas ainda é proibido. Que outras razões podem existir para o 403 e de que maneiras eu posso alterar os comandos wgete curlpara superá-los?

(não se trata de conseguir o arquivo - sei que posso salvá-lo no meu navegador; trata-se de entender por que as ferramentas de linha de comando funcionam de maneira diferente)

atualizar

Obrigado a todas as excelentes respostas dadas a esta pergunta. O problema específico que encontrei foi que o servidor estava verificando o referenciador. Adicionando isso à linha de comando, eu poderia obter o arquivo usando curle wget.

O servidor que verificou o referenciador saltou através de um 302 para outro local que não executou nenhuma verificação; portanto, um curlou wgetdaquele site funcionou corretamente.

Se alguém estiver interessado, isso aconteceu porque eu estava lendo esta página para aprender sobre CSS incorporado e estava tentando ver o css do site como exemplo. O URL real com o qual estava tendo problemas era esse e o curlque acabei sendo é

curl -L -H 'Referer: http://css-tricks.com/forums/topic/font-face-in-base64-is-cross-browser-compatible/' http://cloud.typography.com/610186/691184/css/fonts.css

e o wget é

 wget --referer='http://css-tricks.com/forums/topic/font-face-in-base64-is-cross-browser-compatible/' http://cloud.typography.com/610186/691184/css/fonts.css

Muito interessante.

Uma solicitação HTTP pode conter mais cabeçalhos que não são definidos por curl ou wget. Por exemplo:

• Cookie: esta é a razão mais provável pela qual uma solicitação seria rejeitada. Vi isso acontecer em sites de download. Dado um cookie key=val, você pode configurá-lo com a opção -b key=val(ou --cookie key=val) para curl.
• Referenciador (es): ao clicar em um link em uma página da web, a maioria dos navegadores costuma enviar a página atual como referenciador. Não deve ser invocado, mas mesmo o eBay não conseguiu redefinir uma senha quando este cabeçalho estava ausente. Então, sim, isso pode acontecer. A curlopção para isso é -e URLe --referer URL.
• Autorização: agora está se tornando menos popular devido à interface do usuário incontrolável da caixa de diálogo nome de usuário / senha, mas ainda é possível. Pode ser configurado curlcom a opção -u user:password(ou --user user:password).
• User-Agent: alguns pedidos produzirão respostas diferentes, dependendo do User Agent. Isso pode ser usado de uma maneira boa (fornecendo o download real em vez de uma lista de espelhos) ou de uma maneira ruim (rejeitar agentes do usuário que não iniciam Mozillaou contêm Wgetou curl).

Normalmente, você pode usar as ferramentas de desenvolvedor do seu navegador (o Firefox e o Chrome suportam isso) para ler os cabeçalhos enviados pelo seu navegador. Se a conexão não estiver criptografada (ou seja, não estiver usando HTTPS), você também poderá usar um sniffer de pacotes como o Wireshark para esse fim.

Além desses cabeçalhos, os sites também podem desencadear algumas ações nos bastidores que mudam de estado. Por exemplo, ao abrir uma página, é possível que uma solicitação seja executada em segundo plano para preparar o link de download. Ou um redirecionamento acontece na página. Essas ações normalmente usam Javascript, mas também pode haver um quadro oculto para facilitar essas ações.

Se você está procurando um método para buscar facilmente arquivos de um site de download, consulte o arado, incluído no arado .

Só quero adicionar às respostas acima que você pode usar o recurso "Copiar como cURL", presente nas ferramentas de desenvolvedor do Chrome (desde a v26.0) e no Firebug (desde a v1.12 ). Você pode acessar esse recurso clicando com o botão direito do mouse na linha de solicitação na guia Rede.

Tentei todas as opções acima, porém sem sorte; usei a ferramenta de navegador dev para obter a sequência de agente do usuário, depois que adicionei o seguinte, sucesso:

--user-agent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"

Dependendo do que você está pedindo, pode ser um cookie. Com o Firefox, você pode clicar com o botão direito do mouse quando estiver na página em questão, "Exibir informações da página". Escolha o ícone "Segurança" e clique no botão "Visualizar cookies".

Para confundir os cookies, o plug-in "Live HTTP Headers" do Firefox é essencial. Você pode ver quais cookies são configurados e quais cookies são enviados de volta ao servidor da web.

wgetpode trabalhar com cookies, mas é totalmente irritante, pois não dá uma dica de que não enviou cookies. Sua melhor aposta é remover todos os cookies relacionados do seu navegador e passar por qualquer sequência inicial de login ou visualização de página. Consulte "Cabeçalhos HTTP ao vivo" para obter cookies e quaisquer parâmetros POST ou GET. Faça o primeiro passo de login wgetusando as opções "--keep-session-cookies" e "--save-cookies". Isso fornecerá um arquivo de cookie que você poderá visualizar com um editor de texto. Use wget --load-cookiescom o arquivo de cookie para as próximas etapas.

Outro motivo para isso acontecer é se o site requer SSL. Seu navegador encaminhará automaticamente de HTTP para HTTPS, mas o curl e o wget não. Portanto, tente a solicitação com HTTPS em vez de HTTP.