아.. 세벌식으로 바꾼지 얼마 안지나서 그런지 글 쓰기 무지하게 힘드네요..ㅋ
제가 주로 가는 학과 커뮤니티에 보면,
회원조회를 할 수 있고 각 회원마다 프로필 이미지를 가지구 있는데요.
파일을
/home/member/pic/memberid
와 같은 식으로 분류해 놓고 있습니다.
맨 마지막 부분(memberid)가 실제 이미지 파일이고
앞의 세개는 디렉토리 입니다.
음. 실제로 직접확인해 보시도록 하는게 제 질문에 대한 답을 얻을 수
있는 가장 빠른 길인것 같습니다.
http://purepond.cafe24.com/test/rediscover
http://purepond.cafe24.com/test/rediscover.jpg
각각을 FF와 IE로 열어보세요. FF 가 제대로 동작하는 것이겠죠?
http://www.caucse.net/member/images/member/ddukbong
도 열어보세요. FF에서는 binary data 가 바로 출력되는것 같네요.
web server 설정에 따라 다운로드 메시지가 뜰 수도 있고
binary data가 출력이 될 수도 있는건지..
헷갈리는구먼유... ㅋㅋ
확장자가 없는 이미지 파일..
-
- 해커
- Posts: 1146
- Joined: 2004 01 15 20:06 36
Re: 제 생각에는
웹서버가 디스크에 있는 파일을 내보낼 때 어떤 MIME type을 HTTP 헤더에 선언할 것인가는 대개 파일 확장자에 의존합니다. (동적으로 내보내는 경우라면 그 서버측 프로그램이 마음대로 할 수 있을 것이고요). 웹 브라우저와 같은 클라이언트가 MIME type을 결정할 때에 최우선적으로 쓰는 방법은 확장자 매핑이 아니랍니다 ( 그 방법으로 fallback해야하는 경우도 있지만). 최우선적으로 써야 할 방법은 써버가 HTTP 헤더로 내보내는 Content-Type의 값입니다. 문제가 된 경우에 확장자를 붙이지 않은 파일에 대해서박민권 wrote:확장자를 적어서 브라우저에게 어떠한 파일 타입인지 가르쳐 주는게 올바르겠죠.
근데 둘다 똑같은 jpg인데 하나는 다운로드가 뜨고 하나는 열려버리는군요.
그 차이는 저도 잘 모르겠습니다. ^^;
Content-Type: application/octet-stream
이라는 기본 MIME type 값을 내보내도록 그쪽 서버가 설정되어 있나 봅니다. 따라서, 이 헤더를 받은 브라우저는 이 MIME type을 믿고 저장하라고 합니다. MS IE는 HTTP 표준을 무시하고 이 경우에도 mime type sniffing을 해서 파일 형식을 지가 '알아서' 결정해서 처리합니다. 이것이 편리할 것 같지만, 그렇지 않습니다. html 소스를 그대로 보여 주고 싶어서 'text/plain'이라고 HTTP 헤더에 적어서 html 파일을 내보내도 MS IE는 지멋대로 html이라고 생각하고 소스를 보여 주지 않고 렌더링해서 보여 줍니다. 또, MIME type sniffing이 정확하지도 않아서 아무 이상이 없는 - acroread를 비롯한 여러 프로그램이 군말 없이 잘 보여 주는 - PDF를 (application/pdf라고 HTTP 헤더가 분명히 붙어 있는) PDF가 아니라면서 저장하라고 하는 황당한 경우도 있습니다.
http://websniffer.org
를 비롯한 http sniffer 사이트에 가시면 http로 전송되는 내용을 보실 수 있습니다.
-
- 서포터즈
- Posts: 52
- Joined: 2005 01 28 11:12 17
- Contact:
빛알갱이님의 얘기대로, 익스의 MIME type sniffing 은 정말 문제가 많습니다. 게다가 확률적으로 동작하기에, 다른 요인이 관여되면 다르게 동작하기도 합니다. 유저 인터페이스 면에서 보면 아주 최악입니다. 사용자 습관 형성도 방해합니다.
전에 xhtml 문서 작성할 때, w3c 에서 강력히 권고하는대로 최상단에 <?xml 이라고 명시를 해준 적이 있었습니다. 브라우저 왔다갔다 하다가 뒤로 돌아오기 했더니 캐시랑 꼬였는지, MIME 을 xml 문서로 해석해서 xhtml 을 xsl 에다가 적용하여, 트리 문서 구조로 보여주는 황당함도 겪었습니다. 웃기죠 -_-;;
게다가 인코딩 자동 검출도 애매한 등, 익스의 그러한 사소한 자기 식대로 알아듣기는 정말로 문제가 많습니다. 이걸 모든 개발자가 거쳐가야 하니 그야말로 현재의 익스는 버그의 원흉이라고까지 할 수 있죠.
p.s
type sniffing 버그 패치가 있었다는 얘길 본 적이 있는데, 그게 언제인지 모르겠네요..
전에 xhtml 문서 작성할 때, w3c 에서 강력히 권고하는대로 최상단에 <?xml 이라고 명시를 해준 적이 있었습니다. 브라우저 왔다갔다 하다가 뒤로 돌아오기 했더니 캐시랑 꼬였는지, MIME 을 xml 문서로 해석해서 xhtml 을 xsl 에다가 적용하여, 트리 문서 구조로 보여주는 황당함도 겪었습니다. 웃기죠 -_-;;
게다가 인코딩 자동 검출도 애매한 등, 익스의 그러한 사소한 자기 식대로 알아듣기는 정말로 문제가 많습니다. 이걸 모든 개발자가 거쳐가야 하니 그야말로 현재의 익스는 버그의 원흉이라고까지 할 수 있죠.
p.s
type sniffing 버그 패치가 있었다는 얘길 본 적이 있는데, 그게 언제인지 모르겠네요..
-
- 해커
- Posts: 1146
- Joined: 2004 01 15 20:06 36
Re: 확장자가 없는 이미지 파일..
앞서 언급한 http sniffer에 위 주소를 넣으면 전자는Thom wrote: http://purepond.cafe24.com/test/rediscover
http://purepond.cafe24.com/test/rediscover.jpg
각각을 FF와 IE로 열어보세요. FF 가 제대로 동작하는 것이겠죠?
Content-Type: text/plain
이란 http header를 내보냅니다. 후자는 'Content-Type: image/jpeg'을 내보내고요. text/plain임에도 화면에 뿌리지 않고 저장하라고 하는 이유는 이처럼 binary data를 text/plain이라고 잘못된 MIME type을 붙여서 내보내는 서버들이 많기 때문에 모질라도 type sniffing(text/*인 경우 바이너리인지 여부를 확인하는 수준의)을 합니다. 확인 결과 바이너리이면 화면에 뿌리지 않고, 저장하라고 하지요.
위의 경우에는Thom wrote: http://www.caucse.net/member/images/member/ddukbong
도 열어보세요. FF에서는 binary data 가 바로 출력되는것 같네요.
web server 설정에 따라 다운로드 메시지가 뜰 수도 있고
binary data가 출력이 될 수도 있는건지..
Content-Type: text/plain; charset=EUC-KR
을 그림 파일에 앞서 보내는 HTTP 헤더에 적어 주고 있습니다. 그렇다면 둘다 똑같은 'text/plain'인데, 왜 charset=EUC-KR이 있고 없고에 따라 다르게 동작하느냐고 물으시겠지요. 그래서, 저도 그것이 '버그'라고 생각했습니다. 그런데, 일부러 그렇게 만들어 놓은 것이더군요. 일부러 그렇게 만든 것이 현명한 것이냐는 더 생각해 보아야 할 문제입니다. 설마 charset까지 붙이면서 text/plain이 아닌 파일에 대해 text/plain이라고 엉터리 헤더를 붙이겠느냐.... 이런 식으로 생각한 것이겠지요. 최대한 HTTP 헤더의 C-T 값을 존중한다는 의미에서...
자세한 내용은 아래 문서에 있습니다.
http://www.mozilla.org/docs/web-develop ... types.html
-
- 해커
- Posts: 724
- Joined: 2005 01 31 22:33 55
- Location: 대한민국
- Contact:
아항! 그렇쿠나~
서버의 설정이 많은 결과를 낳는군요. 제가 서버에 너무 무지해서 ㅠ_ㅠ빛알갱이 wrote:앞서 언급한 http sniffer에 위 주소를 넣으면 전자는
Content-Type: text/plain
이란 http header를 내보냅니다. 후자는 'Content-Type: image/jpeg'을 내보내고요. text/plain임에도 화면에 뿌리지 않고 저장하라고 하는 이유는 이처럼 binary data를 text/plain이라고 잘못된 MIME type을 붙여서 내보내는 서버들이 많기 때문에 모질라도 type sniffing(text/*인 경우 바이너리인지 여부를 확인하는 수준의)을 합니다. 확인 결과 바이너리이면 화면에 뿌리지 않고, 저장하라고 하지요.
위의 경우에는
Content-Type: text/plain; charset=EUC-KR
을 그림 파일에 앞서 보내는 HTTP 헤더에 적어 주고 있습니다. 그렇다면 둘다 똑같은 'text/plain'인데, 왜 charset=EUC-KR이 있고 없고에 따라 다르게 동작하느냐고 물으시겠지요. 그래서, 저도 그것이 '버그'라고 생각했습니다. 그런데, 일부러 그렇게 만들어 놓은 것이더군요. 일부러 그렇게 만든 것이 현명한 것이냐는 더 생각해 보아야 할 문제입니다.
빛알갱이님의 답변을 보고 LiveHTTP로 확인해본 결과 정말 그렇더군요.
이런 생각도 있지 않을까요? 일부러 뿌려주고 싶은 사람이 있을경우를 생각해서...설마 charset까지 붙이면서 text/plain이 아닌 파일에 대해 text/plain이라고 엉터리 헤더를 붙이겠느냐.... 이런 식으로 생각한 것이겠지요.
바이너리를 뿌리고 싶은 사람도 있지 않을까요? ㅡㅡ;
Who is online
Users browsing this forum: Ahrefs [Bot], Semrush [Bot] and 1 guest