https://datatracker.ietf.org/doc/html/rfc7230#section-3

• 메시지 포맷은 0개 이상의 헤더 필드를 가지고 있음.
• 빈 라인은 헤더 섹션의 종료를 의미한다.
  • ( 바디가 있을 경우 바디 시작 )

HTTP-message   = start-line
                      *( header-field CRLF )
                      CRLF
                      [ message-body ]

• 수신자는 HTTP 메시지 반드시 US-ASCII와 호환이 되는 것으로 인코딩을 해야한다.

  • 유니코드 문자열로 할 경우, 인코딩에 상관없이 보안에 취약점이 생길 수 있다.

    • 아직 무슨 말인지 잘 모르겠음

    A recipient MUST parse an HTTP message as a sequence of octets in an
       encoding that is a superset of US-ASCII [USASCII].  Parsing an HTTP
       message as a stream of Unicode characters, without regard for the
       specific encoding, creates security vulnerabilities due to the
       varying ways that string processing libraries handle invalid
       multibyte character sequences that contain the octet LF (%x0A).
       String-based parsers can only be safely used within protocol elements
       after the element has been extracted from the message, such as within
       a header field-value after message parsing has delineated the
       individual fields.  
    
    <https://datatracker.ietf.org/doc/html/rfc7230#section-3>
    

    • 송신자는 start-line과 첫번째 헤더 필드 사이에 공백을 두어서는 안된다.

      • 수신자는 만약 공백 때문에 HTTP 메시지가 유효하지 않으면

        • 메시지를 거부
        • 적절한 형식의 헤더 필드를 받을 수 있을 때까지 헤더 처리를 할 수 있는 무언가를 만들어야함.

      • Header에서 처리해야할 것 같음

        

        • statusLIne과 header는 같은 계층으로 봐야하는 게 아닌지?
          • message가 왔을 때, statusLine이 생성됨. header가 없는 경우가 있을 수 있음.
          • 공백 처리할 때 책임이 헤더가 아닌 메시지에 들어가야함.
          • 이런 이유로 statusLine 위치가 옮겨져야하지 않을까?
            • 옮긴다면, content-length 불러오는 고민도 해결될 듯

    • 공백의 존재

      • 서버에 대한 공격시도가 될 수 있음
      • 헤더의 필드를 무시하거나, 새로운 요청처럼 서버가 읽을 수 있음
        • 우리가 처리 해야할 부분

    • 프로젝트 테스트케이스에 넣어서, 방어가 가능한지 확인 필요

    • 서버에서 연결을 끊어버렸을 때, 종료 response를 주면,

    • 클라이언트가 새로 연결해서 다음 구문들이 서버한테 오는건지? 알아봐야함