HTTP 표준을 무시하는 KTF

일반 사용자들이 직접 접할 수 없는 일이긴하지만, 친한 개발자 한 명이 겪은 일을 소개한다.

이번에도 문제를 일으킨 것은, UTF-8으로 XML 요청해도 응답이 EUC-KR로 날아와서 엿을 먹이는(…) 대형통신사 중 하나인 KTF의 사례.

대략 다음과 같은 상황을 겪고 있었다.

ㅊ: SOAP 요청을 (HTTP 연결을 통해) 개발 서버에 보내면 바로 응답이 오는데
ㅊ: 실제로 상용 서버에 올리면 15초씩 걸려요

뭔가 IRC 채널의 사람들이 모여서 고민하다가,

ㅊ: HTTP 타임아웃이 15000ms네요(=15초) 그리고 Keep-Alive 설정이 켜져있음
rein: Content-Length 안오는거 아닌가요?
rein: 그거 안오면 연결이 끊겨야 HTTP응답을 받은게 됨
ㅊ: Content-Length 가 오는 것 같은데요 ((메세지 덤프를 본 상황))

Content-Length: 530
Connection: Keep-Alive
Keep-Alive: timeout=15, max=100
Content-Type: text/xml; charset=UTF-8

같은 상황을 감지. 의심한 것은 역시 Keep-Alive(on) + Timeout 후에야 HTTP 응답을 읽은 것이었는데, 실제로 그러했다.

이유가 좀 엽기적인데,

실제 HTTP 응답의 헤더 전체가 이렇게 생겨먹었다.

ㅊ: Content-Length 가 두 번 와요
ㅊ: python 의 httplib 이 이걸 Content-Length: 530, 530 으로 올려보냄

그리고 “530, 530” 이란 값은 논리적으로 무의미하므로 None으로 해석되고, httplib은 Content-Length 가 없는 것으로 간주, 소켓이 끊길 때 까지 기다린다.(=즉 타임아웃이 나야한다)

HTTP 표준에 따르면, (thanx to ipkn)

<@ipkn>  Multiple message-header fields with the same field-name may be
<@ipkn>    present in a message if and only if the entire field-value for that
<@ipkn>    header field is defined as a comma-separated list [i.e., #(values)].
<@ipkn>    It MUST be possible to combine the multiple header fields into one
<@ipkn>    “field-name: field-value” pair, without changing the semantics of the
<@ipkn>    message, by appending each subsequent field-value to the first, each
<@ipkn>    separated by a comma.
<@ipkn> 필드네임
<@ipkn> 여러개로오는건
<@ipkn> 컴마붙인거랑같아야함
<@ipkn> rfc 2068 page 30
<@ipkn> 에 있네여

라서, python이 올려보낸 것 처럼, 반복해서 나온 HTTP 헤더 필드를 , 로 묶어서 보내는 게 맞음. 그리고 논리적으로 이런 목록의 의미가 없으므로 -_-;; 사례에 나온 “ㅊ”씨는 이걸 우회하는 코드를 httplib에 추가해서 땜빵.

ㅊ:   length = self.msg.getheader(’content-length’).partition(’,’)[0]  로 해결

…좀 슬프네요 orz

ps. 근데 웃기는건 개발 서버랑 서비스되고있는 상용 서버 설정이 다르다는 것. KTF 서비스 파트 분들 반성 좀 하시죠?

덤: 상용서버/개발서버 설정이 다르다는 것은 개발서버는 Keep-alive가 없어서 Content-Length가 이상하게 해석되도 연결이 끊겨서 바로 응답이 온걸로 간주되기 때문에 제대로 동작(…)했는데 상용 서버는 그렇지 않았다는 것…