일부 Tumblr 페이지의 이미지가로드되지 않지만 wget을 사용하는 이유는 무엇입니까?


8

“일부 페이지가로드되지 않음”으로 인해 친구가 인터넷에 접속할 수 있도록 도와 주면서 문제는 특정 블로그의 이미지 게시물 이미지가 브라우저에로드되지 않는 것입니다. 다음과 같은 이유로 이상하다고 생각했습니다.

  1. 게시물의 일부인 이미지 만로드되지 않습니다. 사용자 아바타, 배너, 헤더, 다양한 테마 및 / 또는 페이지 관련 이미지가 여전히 나타납니다.
  2. 컴퓨터의 모든 브라우저에서 발생합니다 (광고 / 스크립트 차단기가 있거나없는 Firefox 및 Chrome / ium에서 테스트 됨).
  3. wget이미지의 직접 링크를 사용하면 작동합니다.
  4. 모든 Tumblr 페이지에 적용되는 것은 아닙니다. 대부분 제대로로드되지만 이미지가로드되지 않은 게시물이있는 페이지 목록을 만들면 대부분 동일한 사용자 그룹에 속한다는 것을 보여줍니다.
  5. 특정 블로그의 이미지 게시물이 브라우저에로드되지 않는 경우 동일한 게시물을 언급 한 다른 블로그 (영향을 받든 그렇지 않든)도 브라우저에 이미지를로드하지 않는다는 점에서 문제는 블로그 고유의 것으로 보입니다. 반대로, 영향을받는 블로그가 영향을받지 않은 블로그의 블로그 인 경우 이미지가 제대로로드됩니다.
  6. 이미지는 사용자가 만든 Tumblr 게시물에서 가져온 것으로, 사용자가 게시 할 이미지를 업로드하고 Tumblr에서 호스팅합니다. (이 예는 해당 블로그 중 하나가 아닌) 예를 들면, 이 화상 포스트 (무작위) 포스트의 이미지에 직접 링크 될 것이다. 이미지 게시물은 자동으로 이미지를에 대한 링크 만들기 텀블러에서 다른 페이지를 A (보통)을 사용하여 더 큰 버전 가까운 사용자가 게시물에 대한 업로드 무엇의 크기입니다 포스트에 사용 된 이미지를.

이런 일이 발생하는 이유는 무엇입니까? 실제로 나를 얻는 부분은 wget작동 한다는 사실 이므로 네트워크 연결에 문제가 없다고 생각할 수 있습니다.

최신 정보:

다음 은 브라우저에로드되지 않은 팔로워 게시물의 예입니다. 기본 블로그는 제대로로드 다른 이미지 게시물이 있습니다. 이것은 게시물의 이미지에 대한 직접 링크이며 다음 은 더 큰 버전을위한 것입니다 (둘 다 여기에로드하지 않음). wget둘 다 작동하지만 Firefox와 직접 연결되면이 오류가 나타납니다.

This XML file does not appear to have any style information associated with it. The document tree is shown below.

<Error>
    <Code>AccessDenied</Code>
    <Message>Access Denied</Message>
    <RequestId>A626307DF577B411</RequestId>
    <HostId>J9GxX1HY9vX3ElWjYf7M48ByvKXLRIwRBJ2al2voS3J/C+WhILWHyd3crFhhNtkXuvG0zaxBTxw=</HostId>
</Error>

RequestID그리고 HostId모든 시간을 변경합니다. 내 친구와 나는 필리핀에 있습니다.

업데이트 [2014/03/08]

추가 지원 및 Tumblr 지원 이메일에 대한 회신 wget으로 일부 경우 작동이 중지되었습니다 (직접 링크에서 403 오류 발생).

업데이트 [2014/03/09]

의 텀블러 규칙을 해제 HTTPS-도처에 보인다 때때로 문제를 해결.


노트 :

  • # 6의 예에서 직접 링크는 모두 동일한 이미지를 가리 킵니다. 그러나 일반적으로 이미지 게시물에 사용 된 이미지 (확대 가능 이미지 페이지와 비교)는 페이지 테마에 맞게 더 작은 버전의 이미지를 사용합니다. 이 예에서는 더 큰 화면 용 테마를 사용하므로 더 작은 버전이 필요하지 않습니다.

내가 5를 올바르게 읽었 으므로 다른 사람이 문제가있는 사람이 발음 한 이미지를 볼 수 없습니까?
Paul

답변을 게시했지만 블로그 게시물에 실제 URL을 제공하고 문제가있는 이미지의 URL을 제공 할 수 있다면 도움이 될 것입니다. 가능한 경우 이러한 세부 정보를 추가하려면 질문을 편집하십시오.
JakeGould

@Paul 나는 브라우저에로드되지 않은 tumblrUser1의 이미지 게시물을 볼 때 tumblrUser2, tumblrUser3 ... tumblrUserN의 게시물을 tumblrUser1의 게시물을 다시 게시하면 브라우저가 다른 사용자의 페이지에도로드 할 수 없음을 의미했습니다. .
maki57

표시하는 예는 모두 PNG 이미지입니다. 친구의 운영 체제는 무엇입니까? 명확히하기 위해 질문을 편집하십시오. PNG 이미지에 연결된 핵심 OS 문제 일 수 있습니다.
JakeGould

@Paul 나는 현재 브라우저에로드되지 않은 tumblrUser1의 이미지 게시물을 볼 때 tumblrUser2, tumblrUser3 ... tumblrUserN의 게시물을 다시 게시하면 브라우저가 다른 사용자에게 이미지를로드 할 수 없음을 의미했습니다. '페이지.
maki57

답변:


10

업데이트 : 이미지가로드되지 않는 핵심 문제는 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.

그러나 그것은 내가 지금 본 것이 아닙니다. 다음은 내가 만든 액세스 권한의 상태 DateX-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.comHighwinds (!?!?)가 관리하는 서버임을 알 수 있습니다. 반대로 원래 사용자가 전달한 초기 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다른 페이지에 포함 된 이미지를 통해 이미지를 가져올 수는 없습니다.


1
그들은 Tumblr가 주최하는 Tumblr 이미지 게시물입니다. 설명을 편집하겠습니다.
maki57

틀릴 수도 있지만 Tumblr가 EdgeCast를 사용했다고 생각했습니다. 어느 쪽이든, 매우 흥미로운 설명에 감사드립니다. 질문에 추가 한 업데이트를 고려할 때 여전히 적용됩니까?
maki57

1
Tumblr가 Amazon CloudFront, EdgeCast 및 Highwinds를 사용하여 사이트에서 CDN 콘텐츠를 제공하는 것처럼 보입니다. 그리고 뉴욕 브루클린의 유리한 지점에서이 오류를 재현 할 수 없습니다. 이러한 Edgecast URL은 실패하지만 링크 된 페이지는 Highwinds CDN을 제공합니다. 내 대답에 대한 자세한 내용이지만 Tumblr와 함께 제기 해야하는 서버 측 문제입니다. 이 사이트가 무엇인지 데스크탑에서 해결할 수있는 것이 아니기 때문에 지금이 질문을 마무리하기 위해 투표 할 것입니다.
JakeGould 2009 년

1
어쨌든 당신은 여전히 ​​"왜"에 대한 나의 주요 질문에 대답 할 수있었습니다. 그래서 나는 여전히 그것에 대해 대단히 감사합니다. 곧 Tumblr에보고하겠습니다. 그동안 친구에게 wget지금 사용하도록 지시하겠습니다 .
maki57

1
@ maki57 글쎄, HTTPS Everywhere의 기능Tumblr 특정 규칙 세트를 살펴보면 플러그인이 Tumblr가 HTTPS를 처리하는 방식에서 결함을 강조하고있는 것처럼 보입니다. 이 플러그인은 HTTPS를 강제 실행하며, 문제가있는 URL은 "HTTPS Everywhere"가 모든 자산을 강제로 사용하는 것으로 보입니다. 텀블러 방법에 기반이되는 수도 일뿐만 아니라 텀블러가 EdgeCast HTTPS 서버 동기화가 제대로되지 않는 것이 될 수 있을까? 나는“HTTPS Everywhere”개발자들에게도 허락 할 것이다.
JakeGould

5

현재이 문제가 있습니다. 이것은 영향을받는 블로그의 예일 뿐입니다. 어리석은 만화 입니다.

그러나 문제가 발견되면 Chrome에서만 발생합니다. 잠시 후, 문제의 원인이 " HTTPS Everywhere "확장이라는 것을 깨달았습니다 . Firefox에 설치했을 때도 같은 문제가있었습니다. 그리고 실제로 HTTPS 규칙 "Tumblr (partial)"을 비활성화하면 (정확하게 생각합니다 *.tumblr.com) 다시 작동합니다.

따라서 문제는 적어도 때때로 HTTPS를 사용하여 이미지에 액세스하면 잘못된 EdgeCast URL로 리디렉션되는 것 같습니다. 예를 들어이 이미지 URL은 정상적으로 작동합니다.

http://36.media.tumblr.com/57d2af15f7b21037364125f9f32c4379/tumblr_nktjzyNkv91s667kio1_1280.png

그러나 프로토콜을에서 (으) http로 변경하면 https작동하지 않는이 URL로 리디렉션됩니다.

https://gs1.wac.edgecastcdn.net/8019B6/data.tumblr.com/57d2af15f7b21037364125f9f32c4379/tumblr_nktjzyNkv91s667kio1_1280.png

이것이 Tumblr 쪽의 오류인지 아닌지 확실하지 않습니다. 클라이언트가 HTTPS를 사용하여 미디어 서버에 액세스하지 않으면 실제로 그들을 비난 할 수 없다고 생각합니다.

편집 : 실제로 문제는 이 GitHub 스레드에보고 된 것처럼 처리 된 것 같습니다 .


1

이동 통신사 T-Mobile에서이 동작이 더 많이 나타났습니다. 이미지 크기를 기반으로 한 일종의 트래픽 형성 또는 해당 항목을 검색 할 때 '난이도 측정 기준'으로 구성된 일부 이동 통신사라고 생각합니다.

1 년 전의 이전 테스트에서 나는 깨진 게시물을 Verizon을 가진 친구와 공유했는데 이미지가 제대로로드되었습니다.

이 이미지를 테스트 할 수 없지만 친구를 사용할 수 없으므로이 이미지가로드되지 않습니다. Chrome을 브라우저로 사용하여 Nexus 5에서 Android (5.0.1)를 실행하고 있습니다.

http://41.media.tumblr.com/efebad51567e927b8f130f9bdc4efae3/tumblr_ndvnpjcBZa1qewacoo1_500.png

이미지를 직접로드하려고하면 504 게이트웨이 시간 초과 오류가 발생합니다.

편집 : 이것은 참조를 위해 실제 이미지를 게시하는 @JakeGould입니다.

여기에 이미지 설명을 입력하십시오

추가 테스트 및 세부 정보 : 저는 LTE 데이터가 부족한 Baltimore MD에 있으며 다음 이미지가 작동했습니다. http://40.media.tumblr.com/a5e0a96d36170c997aabad7efc630d3e/tumblr_njnalkSD7M1s5cyzso1_500.jpg

추가 테스트 결과 PNG가 문제가되지 않는 것으로 나타났습니다. 내가 맞은 다른 이미지들 대부분은 png와 jpg를 혼합 한 것이지만 모두 "41"이 아닌 서버에있었습니다.

마지막 메모 : 집에 돌아 왔는데, Wi-Fi를 내 휴대 전화와 함께-테스트 한 장치와 함께-테스트 한 장치로, 504로 인해 볼 수 없었던 모든 사진을 볼 수 있습니다.

편집 : 수퍼 유저를 처음 사용하고 게시물을 자르고 편집하여보다 사실적이고 토론이 적었습니다.

업데이트 : 문제는 LTE와 관련이있는 것 같습니다. tumblr를로드하고로드하지 않을 이미지를 찾았으며 휴대 전화를 3g로 낮추고 페이지를 다시로드하면 모든 이미지가 표시됩니다. 전화를 다시 LTE로 되돌리고 캐시를 지우고 이전에 LTE에서로드되지 않은 이미지가로드됩니다.
(나는 다시 테스트하고 지금은 재생할 수 없습니다. 따라서 위의 행동은 우연 일 수 있습니다.)


이것은 좋은 정보이지만 실제 위치에 대한 세부 정보를 제공 할 수 있다면 도움이 될 수도 있습니다. 미국 뉴욕의 브루클린에서 이미지가 잘 연결되어 있음을 알 수 있습니다. 그리고 나의 관점에서 이미지는 Highwinds CDN에 의해 ​​전달되고 있습니다.
JakeGould
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.