¿Por qué el curl y el wget dan como resultado un 403 prohibido?

Intento download un file con wget y curl y se rechaza con un error 403 (prohibido).

Puedo ver el file usando el browser web en la misma máquina.

Intento nuevamente con el agente de usuario de mi browser, 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 commands wget y curl para superarlos?

(No se trata de poder get el file; sé que puedo savelo desde mi browser, se trata de comprender por qué las herramientas de la command-line funcionan de manera diferente)

actualizar

Gracias a todas las excelentes respuestas dadas a esta pregunta. El problema específico que me encontré fue que el server estaba revisando el referente. Al agregar esto a la línea de command, pude get el file usando curl y wget .

El server que verificó la reference rebotó a través de un 302 a otra location que no realizó ninguna comprobación en absoluto, por lo que un curl o wget de ese sitio funcionó limpiamente.

Si alguien está interesado, esto se debe a que estaba leyendo esta página para aprender sobre CSS embedded y estaba tratando de ver el CSS del sitio como ejemplo. La URL real con la que estaba teniendo problemas era esta y la curl que terminé 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 request HTTP puede contener más encabezados que no estén configurados por curl o wget. Por ejemplo:

  • Cookie: esta es la razón más probable por la cual una request sería rechazada, he visto esto suceder 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): onclick en un enlace en una página web, la mayoría de los browseres tienden a enviar la página actual como reference. No se debe confiar en eso, pero incluso eBay no pudo restablecer una contraseña cuando este encabezado estaba ausente. Entonces sí, puede suceder. La opción curl para esto es -e URL y --referer URL .
  • Autorización: ahora se está volviendo less popular debido a la interfaz de usuario incontrolable del cuadro de dialog nombre de usuario / contraseña, pero aún es posible. Se puede configurar en curl con la opción -u user:password (o --user user:password ).
  • User-Agent: algunas requestes arrojarán respuestas diferentes según el agente de usuario. Esto se puede usar de una buena manera (proporcionando la descarga real en lugar de una list de réplicas) o de una manera incorrecta (rechaza los agentes de usuario que no comienzan con Mozilla o contienen Wget o curl ).

Normalmente puede utilizar las herramientas de desarrollo de su browser (Firefox y Chrome lo admiten) para leer los encabezados enviados por su browser. Si la connection no está encriptada (es decir, no está usando HTTPS), entonces también puede usar un analizador de packages 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 request en el background para preparar el enlace de descarga. O ocurre una networkingirecció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 está buscando un método para get fácilmente files de un sitio de descarga, eche un vistazo al arado, incluido con el arancel compartido.

Solo quiero agregar a las respuestas anteriores que podría usar la function "Copiar como CURRICULUM" presente en las herramientas de desarrollo de Chrome (desde v26.0) y Firebug (desde v1.12 ). Puede acceder a esta function haciendo clic con el button derecho en la fila de request en la pestaña Red.

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

Para descifrar las cookies, el complemento Firefox "Live HTTP Headers" es esencial. Puede ver qué cookies se establecen y qué cookies se envían nuevamente al server web.

wget puede funcionar con cookies, pero es totalmente exasperante, ya que no da indicios de que no haya enviado cookies. Su mejor opción es eliminar todas las cookies relacionadas de su browser, y pasar por cualquier inicio de session inicial o secuencia de visualización de página que tome. Consulte "Encabezados HTTP en vivo" para ver las cookies y los parameters POST o GET. Haga el primer paso de inicio de session con wget usando las opciones "–keep-session-cookies" y "–save-cookies". Eso le dará un file de cookies que puede ver con un editor de text. Use wget --load-cookies con el file de cookies para los próximos pasos.

Intenté todo lo anterior pero sin suerte; Utilicé la herramienta del browser dev para get 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" 

Otra razón por la que esto puede ocurrir es si el sitio requiere SSL. Su browser se reenviará automáticamente de HTTP a HTTPS pero curl y wget no lo harán. Intente la request con HTTPS en lugar de HTTP.