업데이트 : 이미지가로드되지 않는 핵심 문제는 EFF의 HTTPS Everywhere 플러그인 / 확장 프로그램 이 일부 Tumblr URL을 처리 하는 방식에서 비롯된 것 같습니다 . 개발자에게 알리고 수정 프로그램이있는 것 같습니다 . 이 답변은 기본적으로 초기 질문에 요약 된대로 문제를 발견하기 위해 수행 한 형사 작업을 분류하며 향후 비슷한 문제가 발생할 경우 추가 디버깅 / 진단에 유용 할 수 있습니다.
편집 : 이미지 거머리에 대한 더 큰 내용이 유효하지 않은 것 같습니다. 따라서 맨 위에 새로운 아이디어를 추가하고 누군가에게 유용 할 수 있도록 이미지 거머리 정보를 맨 아래에 둡니다.
Amazon CloudFront CDN 아이디어
Amazon CloudFront CDN 설정에 대한 실제 경험뿐만 아니라 제공 한 URL을 사용하여 무언가를 발견 한 것 같습니다. Tumblr의 Amazon CloudFront CDN 구성이 어떤 이유로 질식하는 것 같습니다. 이것이 내가 생각하는 이유입니다.
이 예제 URL을 보자 :
http://36.media.tumblr.com/d685b02fdf2d3f167c22d9a97e27e87a/tumblr_nfpq5qPZ4v1tognpro1_1280.png
이제 curl -I
해당 파일에 대한 헤더 정보를 얻기 위해 실행 해 보겠습니다 .
curl -I http://36.media.tumblr.com/d685b02fdf2d3f167c22d9a97e27e87a/tumblr_nfpq5qPZ4v1tognpro1_1280.png
그 결과는 다음과 같습니다.
HTTP/1.1 200 OK
Content-Type: image/png
Content-Length: 782141
Connection: keep-alive
Accept-Ranges: bytes
Cache-Control: max-age=1209600
Date: Thu, 05 Mar 2015 02:15:44 GMT
Server: nginx
X-Cache: Miss from cloudfront
Via: 1.1 7e54fc06cd70e4752fe050bbe5c130be.cloudfront.net (CloudFront)
X-Amz-Cf-Id: QyIUyzfaJJN3PU_xWkW0P-D2kjg_1cVenKzFAoY2PubgZQlBHWorZQ==
이제 여기서주의해야 할 사항은 Date
(CloudFront 엔드 포인트의 파일 날짜 및 시간) 및 X-Cache
(Amazon content delivery 상태) 헤더입니다. Amazon CloudFront의 일반적인 동작은 첫 번째 액세스가 "클라우드 프론트에서 미스"를 전달한 후 curl -I
바로 다른 작업을 수행하는 경우을 (를) 수행 해야합니다 Hit from cloudfront
.
그러나 그것은 내가 지금 본 것이 아닙니다. 다음은 내가 만든 액세스 권한의 상태 Date
와 X-Cache
상태입니다.
Date: Thu, 05 Mar 2015 02:19:37 GMT
= X-Cache: Miss from cloudfront
Date: Thu, 05 Mar 2015 02:19:39 GMT
= X-Cache: Miss from cloudfront
Date: Thu, 05 Mar 2015 02:19:44 GMT
= X-Cache: Miss from cloudfront
Date: Thu, 05 Mar 2015 02:19:50 GMT
= X-Cache: Miss from cloudfront
Date: Thu, 05 Mar 2015 02:19:50 GMT
= X-Cache: Hit from cloudfront
Date: Thu, 05 Mar 2015 02:19:50 GMT
= X-Cache: Hit from cloudfront
Date: Thu, 05 Mar 2015 02:19:50 GMT
= X-Cache: Hit from cloudfront
Hit from cloudfront
끝 부분에 가까운 정확한 데이터를 가진 여러 항목이있는 이유 는 CDN에서 발생하기 때문입니다. CDN의 엔드 포인트에 파일이 있으면 파일 Date
의 실제 작성 / 수정 날짜와 연관됩니다. 엔드 포인트가 있습니다.
처음 4 개의 액세스는 서로 다른 날짜 / 시간으로 몇 초 간격으로 있으며 모두 액세스 할 수 있습니다 Miss from cloudfront
. 이는 CDN 엔드 포인트가 그 당시 해당 파일에 액세스하려는 시도가 있었으며 모든 시도가 누락되었다는 것을 다시 보여줍니다.
그래서 이것에 대한 나의 안락 의자 평가는 Tumblr의 시스템이 Amazon CloudFront CDN을 따르지 않거나 Amazon CloudFront CDN이 Tumblr를 따라 가지 않는다는 것입니다. 그러나 어떤면에서는 서버 측에서 일이 잘못되었습니다. 이것은 CDN이므로 한 위치에서 파일에 액세스하는 사람에게는 문제가없는 반면 다른 위치에있는 누군가는 이미지를 보는 데 문제가있을 수 있습니다.
말할 것도없이, 나는 이것이 클라이언트 측에서 쉽게 정리 될 수 있다고 생각하지 않습니다.
편집 : 따라서 원래 포스터에는 새로운 URL이 추가되었지만 여전히 서버 측 문제를 가리키고 있지만 레코드의 세부 정보를 게시하고 싶었습니다.
EdgeCast & Highwinds CDN 아이디어
원래 포스터에 더 구체적인 내용이 추가되었으므로 다음은 예제로 사용되는 블로그 게시물을 기반으로 한 자세한 내용입니다.
http://claystorks.tumblr.com/post/112741831192/soulmister-claystorks-windspeare-explain
이 이미지 URL은 해당 게시물의 URL 예제로 제공됩니다.
https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_500.png
https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_1280.png
그리고이 두 이미지 URL은 실제로 실패합니다. 그러나 미국 뉴욕 브루클린의 블로그 게시물의 원본 코드를 보면 EdgeCast ( gs1.wac.edgecastcdn.net
) URL 이 보이지 않습니다 . 오히려 내가보고있는 URL은 다음과 같습니다.
http://41.media.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_500.png
http://41.media.tumblr.com/76493f424ebb3b62d6de43e53643180a/tumblr_nkps82DdCh1sjn35qo1_1280.png
첫 번째 생각은 원래 포스터가 왜 EdgeCast ( gs1.wac.edgecastcdn.net
)를 보는 것 입니다. 그러나 추적 경로를 수행하면 41.media.tumblr.com
Highwinds (!?!?)가 관리하는 서버임을 알 수 있습니다. 반대로 원래 사용자가 전달한 초기 URL은 36.media.tumblr.com
호스트 이름을 사용하고 있으며 Amazon CloudFront CDN 서버에서 관리되는 것을 볼 수 있습니다.
내가 전에 말했던 것은 모두 Tumblr와 CDN 관리의 서버 측 문제인 것 같습니다. 그러나 저는 미국 뉴욕 브루클린에서 Highwinds CDN 서버와 Amazon CloudFront CDN 서버에서 예상대로 콘텐츠가 제공되는 것을 분명히보고 있습니다. 이러한 EdgeCast URL은 어디에서 왔으며 어떻게 / 어떻게 실패하는지는 클라이언트 측에서 누구나 제어 할 수 없습니다. 데스크톱 최종 사용자가이 문제를 해결할 수있는 방법이 없기 때문에 Tumblr 기술 직원에게 문의해야 할 사항입니다.
이미지 거머리 아이디어
더 이상 관련이 없지만 참조를 위해 여기에 있습니다.
당신이 이것을 말하면 단서가됩니다.
wget
이미지의 직접 링크를 사용하면 작동합니다.
많은 사이트에는 이미지 리칭을 방지하는 규칙 (일반적으로 Apache를 통해 설정)이 있습니다. 이러한 규칙의 작동 방식에 대한 자세한 내용 은 여기에 제공되며 다음 과 같이 요약됩니다.
.htaccess를 사용하면 서버에서 핫 링크를 허용하지 않을 수 있으므로 예를 들어 사이트의 이미지 또는 CSS 파일에 연결하려는 사용자는 차단되거나 (예 : 깨진 이미지와 같은 요청 실패) 다른 콘텐츠 ( 즉 : 화난 사람의 이미지).
설명과 이미지를 통해 이미지에 액세스 할 수 있다는 사실을 바탕으로 wget
문제가있는 이미지는 사용자가 Tumblr에서 호스팅하는 것이 아니라 Tumblr 블로그에 있지만 실제로는 다른 블로그에서 호스팅되는 이미지라고 생각합니다. 대지.
표준 이미지 Leeching 절차가 시행되면, 다른 사이트에서 호스팅되는 한 사이트에서 내장 이미지를 보았을 때 (가려움을 차단 함) 이미지 링크가 끊어 지거나 "Lee Leeching!" 이미지가 반환되고 있습니다. 이미지를 요청하는 페이지가 이미지를 호스팅하는 도메인과 일치하는지 확인하기 위해 해당 예제 페이지의 규칙과 같은 기본 안티 리칭 규칙이 이미지 참조자를 교차 확인하기 때문입니다.
따라서 이미지를 통해 wget
액세스하면 이미지에 직접 액세스합니다. 따라서 이미지 거머리 규칙이 적용되지 않습니다. 따라서 wget
다른 페이지에 포함 된 이미지를 통해 이미지를 가져올 수는 없습니다.