¿por qué curl y wget resultarían en un 403 prohibido?

Intento descargar un archivo con wgety curlse rechaza con un error 403 (prohibido).

Puedo ver el archivo usando el navegador web en la misma máquina.

Intento nuevamente con el agente de usuario de mi navegador, obtenido por http://www.whatsmyuseragent.com . Hago esto:

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

y

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

Pero todavía está prohibido. ¿Qué otras razones podría haber para el 403, y de qué maneras puedo alterar los comandos wgety curlpara superarlos?

(no se trata de poder obtener el archivo; sé que puedo guardarlo desde mi navegador; se trata de entender por qué las herramientas de línea de comandos funcionan de manera diferente)

actualizar

Gracias a todas las excelentes respuestas dadas a esta pregunta. El problema específico que encontré fue que el servidor estaba verificando el referente. Al agregar esto a la línea de comandos, podría obtener el archivo usando curly wget.

El servidor que verificó el referidor rebotó a través de un 302 a otra ubicación que no realizó ninguna verificación, por lo que uno curlo wgetde ese sitio funcionó limpiamente.

Si alguien está interesado, esto ocurrió porque estaba leyendo esta página para aprender sobre CSS incrustado y estaba tratando de mirar el CSS del sitio para ver un ejemplo. La URL real con la que estaba teniendo problemas era esta y curlterminé con es

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

y el wget es

 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

Muy interesante.

Una solicitud HTTP puede contener más encabezados que no están establecidos por curl o wget. Por ejemplo:

• Cookie: esta es la razón más probable por la que se rechazaría una solicitud, he visto que esto sucede en los sitios de descarga. Dada una cookie key=val, puede configurarla con la opción -b key=val(o --cookie key=val) para curl.
• Referer (sic): al hacer clic en un enlace en una página web, la mayoría de los navegadores tienden a enviar la página actual como referencia. No se debe confiar en él, pero incluso eBay no pudo restablecer una contraseña cuando este encabezado estaba ausente. Entonces sí, puede suceder. La curlopción para esto es -e URLy --referer URL.
• Autorización: esto se está volviendo menos popular ahora debido a la IU incontrolable del diálogo de nombre de usuario / contraseña, pero aún es posible. Se puede configurar curlcon la opción -u user:password(o --user user:password).
• User-Agent: algunas solicitudes generarán diferentes respuestas según el User Agent. Esto se puede usar de una buena manera (proporcionando la descarga real en lugar de una lista de espejos) o de una manera incorrecta (rechazar agentes de usuario que no comienzan con Mozilla, o contienen Wgeto curl).

Normalmente puede usar las herramientas de desarrollador de su navegador (Firefox y Chrome lo admiten) para leer los encabezados enviados por su navegador. Si la conexión no está encriptada (es decir, sin usar HTTPS), también puede usar un sniffer de paquetes como Wireshark para este propósito.

Además de estos encabezados, los sitios web también pueden desencadenar algunas acciones detrás de escena que cambian de estado. Por ejemplo, al abrir una página, es posible que se realice una solicitud en segundo plano para preparar el enlace de descarga. O ocurre una redirección en la página. Estas acciones suelen hacer uso de Javascript, pero también puede haber un marco oculto para facilitar estas acciones.

Si usted está buscando un método para captar fácilmente archivos desde un sitio de descarga, echar un vistazo a plowdown, incluido con reja de arado .

Solo quiero agregar a las respuestas anteriores que podría usar la función "Copiar como cURL" presente en las herramientas de desarrollador de Chrome (desde la v26.0) y Firebug (desde la v1.12 ). Puede acceder a esta función haciendo clic derecho en la fila de solicitud en la pestaña Red.

Intenté todo lo anterior sin embargo, no hubo suerte; utilicé la herramienta de navegador dev para obtener la cadena de agente de usuario, una vez que agregué lo siguiente, éxito:

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

Dependiendo de lo que esté pidiendo, podría ser una cookie. Con Firefox, puede hacer clic con el botón derecho cuando se encuentra en la página en cuestión, "Ver información de la página". Elija el icono "Seguridad" y luego haga clic en el botón "Ver cookies".

Para descifrar las cookies, el complemento Firefox "Live HTTP Headers" es esencial. Puede ver qué cookies se configuran y qué cookies se envían de vuelta al servidor web.

wgetpuede funcionar con cookies, pero es totalmente irritante, ya que no da una pista de que no envió cookies. Su mejor opción es eliminar todas las cookies relacionadas de su navegador y pasar por el inicio de sesión inicial o la secuencia de visualización de la página. Mire en "Encabezados HTTP en vivo" las cookies y cualquier parámetro POST o GET. Realice el primer paso de inicio de sesión con las wgetopciones "--keep-session-cookies" y "--save-cookies". Eso le dará un archivo de cookies que puede ver con un editor de texto. Úselo wget --load-cookiescon el archivo de cookies para los próximos pasos.

Otra razón por la que esto puede suceder es si el sitio requiere SSL. Su navegador reenviará automáticamente de HTTP a HTTPS pero curl y wget no lo harán. Por lo tanto, intente la solicitud con HTTPS en lugar de HTTP.