원박스에서 이미지를 다운로드하는 기능이 깨진 것 같습니다. 최근 원박스 또는 보안 미디어 관련 변경 사항으로 인한 회귀 버그일 수 있습니다. @vinothkannans 확인해 주실 수 있을까요?
예: https://www.samsung.com/us/mobile/galaxy-z-flip을 원박싱하면 이미지가 HTTP로 로드되기 때문에 이미지가 표시되지 않습니다.
원박스에서 이미지를 다운로드하는 기능이 깨진 것 같습니다. 최근 원박스 또는 보안 미디어 관련 변경 사항으로 인한 회귀 버그일 수 있습니다. @vinothkannans 확인해 주실 수 있을까요?
예: https://www.samsung.com/us/mobile/galaxy-z-flip을 원박싱하면 이미지가 HTTP로 로드되기 때문에 이미지가 표시되지 않습니다.
문제는 URL "http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg"에서 onebox 이미지를 다운로드할 때 파일이 “.webp” 형식(samsung-logo-191-1.webp)으로 반환된다는 것입니다. 따라서 authorized_extensions 사이트 설정에 “.webp” 파일 형식이 화이트리스트에 포함되어 있지 않아 다운로드할 수 없습니다.
Favicon은 “.ico” 파일이기 때문에 다운로드되지 않습니다. 기본적으로 onebox에서 “ico” 파일을 허용해야 할까요?
크롬 사용자 에이전트를 사용했기 때문에 webp만 제공되는 건 아닌지 궁금합니다 ![]()
그렇게 생각하지 않습니다. Firefox에서 수동으로 다운로드해도 webp 파일이 반환됩니다.
저희가 사용하는 Firefox 버전(77.0.1 (64-bit) for MacOS)에서는 위 URL에 대한 요청의 Accept 헤더가 다음과 같습니다:
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
(즉, 사용 가능한 경우 브라우저가 image/webp 형식을 요청하고 있다는 뜻입니다)
반면 Safari의 Accept 헤더는 다음과 같습니다:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
그리고 삼성 웹서버는 jpeg 형식을 반환합니다. Safari에서는 Onebox가 올바르게 표시되며(이미지가 포함됨).
Samsung은 이러한 파일을 서빙하기 위해 Akamai Image Manager를 사용하고 있습니다.
Accept 헤더에 image/jpeg,image/gif를 전달하면 예상대로 image/jpeg가 반환됩니다.
wget --header="Accept: image/jpeg,image/gif" http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
--2020-11-13 11:43:58-- http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
Resolving image-us.samsung.com (image-us.samsung.com)... 23.217.144.69
Connecting to image-us.samsung.com (image-us.samsung.com)|23.217.144.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 83094 (81K) [image/jpeg]
Saving to: ‘samsung-logo-191-1.jpg.6’
Discourse는 FileHelper.download를 호출하여 이미지를 가져오려고 시도하며, 이는 FinalDestination.get를 호출하고, 궁극적으로 다음 UserAgent로 파일을 요청합니다:
Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36
따라서 위에서와 동일한 Accept 헤더를 사용하되, 해당 사용자 에이전트를 추가하여 동일한 이미지를 요청하면 다음 결과가 나옵니다:
wget --header="Accept: image/jpeg,image/gif" --header="User-Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36" http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
--2020-11-13 11:52:50-- http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
Resolving image-us.samsung.com (image-us.samsung.com)... 23.217.144.69
Connecting to image-us.samsung.com (image-us.samsung.com)|23.217.144.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 45540 (44K) [image/webp]
Saving to: ‘samsung-logo-191-1.jpg.10’
그리고 image/webp가 반환되었습니다. Accept 헤더를 무시하고 사용자 에이전트 기반으로 최적의 파일 형식을 결정하는 자체 로직을 사용하는 것으로 보입니다.
Apple은 과거에 webp를 지원하지 않았으므로, 이를 시도해 보겠습니다:
wget --header="Accept: image/jpeg,image/gif" --header="User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15" http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
--2020-11-13 12:27:02-- http://image-us.samsung.com/SamsungUS/home/samsung-logo-191-1.jpg
Resolving image-us.samsung.com (image-us.samsung.com)... 23.217.144.69
Connecting to image-us.samsung.com (image-us.samsung.com)|23.217.144.69|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 83094 (81K) [image/jpeg]
Saving to: ‘samsung-logo-191-1.jpg.16’
성공했습니다!
웹 서버는 Accept 헤더를 항상 준수해야 하며, 이를 능가하려는 시도를 하지 않아야 한다는 강력한 주장을 할 수 있습니다. 반면, 특정 사용자 에이전트 문자열을 제시한다면 그 사용자 에이전트처럼 행동할 준비가 되어 있어야 한다는 반론도 가능합니다(사용자 에이전트 위장은 흔하지 않으며 다양한 용도가 있습니다).
우연히도 Apple은 최근 출시된 iOS 14와 어제 출시된 MacOS Big Sur의 Safari에 webp 지원을 추가했으므로, 이를 지원해야 할 것 같습니다(기본 허용 확장자로 추가하고, 최적화 및 리사이즈 등을 위해 ImageMagick을 webp를 지원하도록 구성하여 libwebp 또는 유사한 라이브러리에 대한 의존성을 도입하는 방식).
Akami 쪽에서 그런 행동을 한 건 정말 나쁘네요. 끔찍하네요.
가짜 User Agent를 바꾸는 게 쉬운 일인가요? 어쨌든 2017년에 출시된 Chrome 58인 척하는 건 더 이상 유지해선 안 됩니다.
@eviltrout 님은 Discourse가 왜 특정 User Agent를 사용하지 않고 가짜 User Agent를 사용하는지에 대한 전체 맥락을 잘 알고 계실 겁니다. 제가 기억하기로는, 가짜 User Agent를 사용하지 않으면 일부 사이트에서 이미지 다운로드와 원박스(Onebox) 기능을 거부하는 경우가 있었습니다. 다음 방법들을 고려해 볼 수 있습니다:
아마도 파일 다운로드 후 “투명한” webp → jpeg 변환을 허용할 수 있을 것입니다. 이렇게 하면 사이트 운영자가 webp를 완전히 지원하지 않는 경우에도 호환되지 않는 이미지를 프록시할 수 있습니다. (이 방법은 다른 특수한 이미지 포맷에도 유용할 수 있습니다.)
아니면, webp를 기본적으로 지원하고 모든 기본 설정에 추가하는 방향으로 나아가는 것도 방법입니다. (아직 이르지는 않은지 궁금하네요.)
불행히도 많은 사이트는 요청이 브라우저처럼 보이지 않는 한 올바른 콘텐츠를 제공하지 않습니다. 이 부분을 변경하면 대부분의 소스가 정상적으로 작동할 것으로 예상하지만, 한두 곳은 문제가 생길 수 있습니다.
원박스는 종종 지뢰찾기(whack-a-mole)와 같습니다. 하나의 버그를 고치면 다른 곳에서 또 다른 버그가 나타나는 식이죠.
Apple이 굴복하여 Safari와 iOS에 지원을 추가하고 있으니, 이제 이 작업을 수행하기에 적절한 시기가 맞는 것 같습니다.
위 커밋에서 .webp 업로드에 대한 지원이 추가되었습니다.
원본 게시물을 다시 생성(rebake)하기 위해 몇 가지 절차를 거친 후, 이 문제가 이제 해결된 것으로 보입니다(즉, ‘Samsung’ 로고가 로컬로 다운로드/캐시되었습니다).
이 이슈는 해결된 것으로 간주할 수 있다고 생각합니다.