HTTP 표준을 무시하는 KTF

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

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

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

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

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

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

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가 이상하게 해석되도 연결이 끊겨서 바로 응답이 온걸로 간주되기 때문에 제대로 동작(…)했는데 상용 서버는 그렇지 않았다는 것…

  1. 메세지 덤프를 본 상황 []

Published by

rein

나는 ...

7 thoughts on “HTTP 표준을 무시하는 KTF”

  1. “올려보낸다”라는 표현이 반환한다는 의미였군. 상대편 서버에 “되돌려준다”라는 의미로 읽고 먼소리가 했음 ;; 아마도 단순한 실수가 테스트 코드에 잡히지 않은게 아닐까 추측.

  2. 오오 저런 표준이 있었군요!
    해더 항목이 같은게 2개일 경우 쉽표로 연결한것과 같게한다니…음 몰랐네요.
    저도 예전 회사서 해더붙인게 받는쪽에서 재대로 안나오고 하는 경우가 있었는데 아마 이거 때문이었나봅니다. ㅜㅜ

  3. KTF, SKT, LGT 다 일해봤지만 제각기 문제가 많지요. 바이너리 이미지를 보내놓고 데이터 크기도 안 알려준다던가, 이번 경우처럼 HTTP 규격 자체가 틀려서 웹 서버가 패킷을 튕겨낸다던가, SOAP은 둘째치고 XML 유효성 검사조차 통과 못한다던가, 또 뭐 있더라…… 애시당초 넘겨준 명세서하고 실제 구현이 다르다 보니 상용서버에 연결해놓고 테스트해보지 않으면 확신 못하죠.

    외주로 개발하는데다가 각 이통사쪽 담당자들의 보직 이동이 심해서 품질 관리가 안 되구요. 거기에 더해 SOAP인 것 보니까 MMS나 기타 부가 서비스 같은데 사실 SMS 같은 기본 서비스가 돈이 되는지라 담당자들이 새 서비스는 내팽겨쳐 둡니다.

  4. 장수원 / 그게 테스트 서버는 Keep-alive가 없었음;

    미나즈키 / 어제 베리즈웹쉐어 만드는 사람들이랑도 나온 얘기지만 사람들이 표준도 제대로 안 읽어보는 것 같음 -_-;;

    최재훈 / 근데 SI말고 그나마 저런 곳은 개발 프로세스가 있을 거라고 생각했는데 아닌가 보군요 -_-;
    차라리 일정 규모 이상의 게임회사들이 한참 낫다는 느낌입니다 -_-;;

Leave a Reply