HTTP 요청에 netcat(nc)과 컬을 사용하는 것의 차이점은 무엇입니까?

HTTP 요청에 netcat(nc)과 컬을 사용하는 것의 차이점은 무엇입니까?

컬을 사용하여 특정 URL을 요청하고 200 OK 응답을 받았습니다.

curl -v www.youtypeitwepostit.com
* About to connect() to www.youtypeitwepostit.com port 80 (#0)
*   Trying 54.197.246.21...
* Connected to www.youtypeitwepostit.com (54.197.246.21) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: www.youtypeitwepostit.com
> Accept: */*
>
< HTTP/1.1 200 OK
...

제목을 파일에 저장하는 경우:

GET / HTTP/1.1
User-Agent: curl/7.29.0
Host: www.youtypeitwepostit.com
Accept: */*

nc그리고 다음 명령(netcat)을 실행해 보십시오 :

nc www.youtypeitwepostit.com 80 < file
HTTP/1.1 505 HTTP Version Not Supported
Connection: close
Server: Cowboy
Date: Wed, 02 Nov 2016 04:08:34 GMT
Content-Length: 0

또 다른 답장을 받았습니다. 200OK의 차이점과 사용방법은 무엇인가요 nc?

요청 헤더에 다른 버전의 HTTP를 사용해 보았고, 잘못된 CRLF를 피하기 위해 수동으로 요청을 입력해 보았고, 선택적 헤더를 제외해 보았습니다. 결과는 비슷합니다.

답변1

관련 RFC,하이퍼텍스트 전송 프로토콜(HTTP/1.1): 메시지 구문 및 라우팅질문에 대한 답변이 포함되어 있습니다. HTTP 요청의 각 줄은 CR/LF로 끝나야 합니다.


HTTP 구문메시지 형식각 헤더 행이 캐리지 리턴( 0x0dASCII 형식)으로 끝나고 그 뒤에 줄 바꿈( 0x0a)이 와야 함을 지정합니다.

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

이는 설명에 더 명확하게 표현되어 있습니다.핫라인 요청:

요청 라인은 메소드 토큰으로 시작하고 공백(SP), 요청 대상, 다른 공백(SP), 프로토콜 버전이 뒤따르고 CRLF로 끝납니다.

 request-line   = method SP request-target SP HTTP-version CRLF

HTTP 요청을 위해 특별히 개발되었기 때문에 curlHTTP 요청을 할 때 이미 적절한 줄 종결자를 사용합니다. 그러나 netcat은 보다 일반적인 프로그램입니다. Unix 유틸리티로서 기본적으로 개행 문자를 줄 종결자로 사용하므로 사용자는 줄이 올바르게 끝나는지 확인해야 합니다.

unix2dos유틸리티를 사용하면 요청 헤더가 포함된 파일을 캐리지 리턴/라인피드 종료를 사용하도록 변환할 수 있습니다.

HTTP 요청을 수동으로 입력하고 최신 버전을 갖고 싶다면 줄 끝 옵션 nc을 사용해야 합니다 .-CCRLF

nc -C www.youtypeitwepostit.com 80

그런데 가장 널리 사용되는 인터넷 프로토콜(예: SMTP)이 CR/LF 줄 끝을 사용한다는 점은 주목할 가치가 있습니다.


일부 웹 서버(예: Apache)는 더 관대하며 개행 문자로만 끝나는 요청 줄을 허용합니다. HTTP 사양에서는 이를 허용합니다.메시지 구문 분석의 견고성부분:

시작 라인과 헤더 필드의 라인 종결자는 시퀀스 CRLF이지만 수신자는 단일 LF를 라인 종결자로 인식하고 이전 CR을 무시할 수 있습니다.

관련 정보