컬과 wget으로 인해 403이 금지되는 이유는 무엇입니까?

컬과 wget으로 인해 403이 금지되는 이유는 무엇입니까?

wget파일을 사용하고 다운로드하려고 했으나 curl403 오류(금지됨)로 인해 거부되었습니다.

동일한 컴퓨터에서 웹 브라우저를 사용하여 파일을 볼 수 있습니다.

다음을 통해 얻은 브라우저의 사용자 에이전트를 사용하여 다시 시도했습니다.http://www.whatsmyuseragent.com. 나는 이렇게 한다:

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

그리고

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

하지만 여전히 금지되어 있습니다. 403에는 또 어떤 이유가 있을 수 있으며, 이를 극복하기 위해 어떤 변경 wgetcurl명령을 내릴 수 있습니까?

(이것은 파일을 얻을 수 있다는 것이 아닙니다. 브라우저에서 파일을 저장할 수 있다는 것을 알고 있습니다. 명령줄 도구가 다르게 작동하는 이유를 이해하는 것입니다.)

고쳐 쓰다

이 질문에 대한 훌륭한 답변에 감사드립니다. 내가 겪고 있는 구체적인 문제는 서버가 리퍼러를 확인하고 있다는 것입니다. 이것을 명령줄에 추가하면 curl파일을 사용할 수 있고 얻을 수 있습니다 wget.

리퍼러를 확인하는 서버는 302와 함께 전혀 확인을 수행하지 않는 다른 위치로 이동하므로 사이트의 일부 curl또는 일부가 wget제대로 작동합니다.

누군가 관심이 있다면 내가 읽고 있기 때문이다이것페이지를 방문하여 임베디드 CSS에 대해 알아보고 사이트의 CSS 예제를 살펴보세요. 문제가 있는 실제 URL은 다음과 같습니다.이것내가 curl결국 한 일은

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

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

흥미로운.

답변1

HTTP 요청에는 컬 또는 wget으로 설정되지 않은 헤더가 더 많이 포함될 수 있습니다. 예를 들어:

  • 쿠키: 요청이 거부되는 가장 큰 이유입니다. 다운로드 사이트에서 이런 일이 발생하는 것을 본 적이 있습니다. 쿠키가 주어지면 (또는 ) 옵션을 사용하여 설정할 key=val수 있습니다 .-b key=val--cookie key=valcurl
  • 리퍼러(sic): 웹페이지의 링크를 클릭할 때 대부분의 브라우저는 현재 페이지를 리퍼러로 보내는 경향이 있습니다. 의존해서는 안 되지만, 이 헤더가 없으면 eBay에서도 비밀번호를 재설정할 수 없습니다. 네, 이런 일이 일어날 수도 있습니다. curl이에 대한 옵션은 -e URL및 입니다 --referer URL.
  • 인증: 이 접근 방식은 사용자 이름/비밀번호 대화 상자의 제어할 수 없는 사용자 인터페이스로 인해 요즘 덜 인기가 있지만 여전히 가능합니다. ( 또는 ) 옵션을 curl사용하여 설정할 수 있습니다 .-u user:password--user user:password
  • 사용자 에이전트: 일부 요청은 사용자 에이전트에 따라 다른 응답을 생성합니다. 이는 좋은 방법(미러 목록 대신 실제 다운로드 제공)으로 사용될 수도 있고 나쁜 방법( 로 시작하지 않거나 Mozilla또는 포함하는 Wget사용자 에이전트 거부 curl)으로 사용될 수도 있습니다.

일반적으로 브라우저의 개발자 도구(Firefox 및 Chrome에서 지원)를 사용하여 브라우저에서 보낸 헤더를 읽을 수 있습니다. 연결이 암호화되지 않은 경우(즉, HTTPS를 사용하지 않는 경우) 이 목적으로 패킷 스니퍼(예: Wireshark)를 사용할 수도 있습니다.

이러한 헤더 외에도 웹 사이트는 상태를 변경하는 몇 가지 비하인드 스토리 작업을 트리거할 수도 있습니다. 예를 들어, 페이지가 열리면 백그라운드에서 다운로드 링크를 준비하라는 요청이 이루어질 수 있습니다. 또는 페이지에서 리디렉션이 발생합니다. 이러한 작업은 일반적으로 Javascript를 사용하지만 이러한 작업을 용이하게 하는 숨겨진 프레임워크가 있을 수도 있습니다.

다운로드 사이트에서 파일을 얻는 쉬운 방법을 찾고 있다면 다음이 포함된 plowdown을 확인하십시오.쟁기.

답변2

운 없이 위의 모든 작업을 시도했습니다. 개발자 브라우저 도구를 사용하여 사용자 에이전트 문자열을 얻은 후 다음을 추가하면 성공했습니다.

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

답변3

위 답변에 추가하고 싶으면 Chrome 개발자 도구(v26.0부터) 및 Firebug(v26.0부터)에서 사용할 수 있는 "cURL로 복사" 기능을 사용할 수 있습니다.v1.12). 네트워크 탭의 요청 라인을 마우스 오른쪽 버튼으로 클릭하여 이 기능에 액세스할 수 있습니다.

답변4

이런 일이 발생하는 또 다른 이유는 사이트에 SSL이 필요한 경우입니다. 브라우저는 자동으로 HTTP에서 HTTPS로 전달되지만 컬과 wget은 그렇지 않습니다. 따라서 HTTP 대신 HTTPS를 사용하여 요청을 시도해보세요.

관련 정보