가지다답변HTTP를 통해 파일 제공nc
{ echo -ne "HTTP/1.0 200 OK\r\n\r\n"; cat some.file; } | nc -l -p 8080
{ echo -ne "HTTP/1.0 200 OK\r\nContent-Length: $(wc -c <some.file)\r\n\r\n"; cat some.file; } | nc -l -p 8080
코멘트설명하다:
두 번째 nc 명령을 사용하지 않는 한 Chrome은 고동을 멈추지 않습니다.
또한 응답 후 nc 명령 show가 종료되는 것은 아닙니다. 다음 명령을 사용하여 계속해서 다시 시작할 수 있습니다
while :; do { echo -ne "HTTP/1.0 200 OK\r\nContent-Length: $(wc -c <some.file)\r\n\r\n"; cat some.file; } | nc -l -p 8080; done
. Ctrl+Z를 사용하여 절전 모드로 전환하세요.
반송이 발생하면 웹 브라우저가 자동으로 URL을 다시 로드한다는 뜻인가요?
Chrome이 점프하는 것을 막기 위해 첫 번째 nc 명령에 추가된 두 번째 nc 명령의 목적이 있습니까 Content-Length: $(wc -c <some.file)
?
URL http://IP:8080/
뒤에 아무 것도 추가하지 않거나 아무 것도 추가하지 않으면 웹 브라우저에서 파일을 가져올 수 있습니다 . 이러한 유연성은 nc
HTTP 프로토콜에서 제공됩니까, 아니면 웹 브라우저에서 제공됩니까?
감사해요.
답변1
Chrome은 전송되는 파일의 크기를 모르기 때문에 명령의 첫 번째 버전을 계속 사용하므로 언제 파일이 모두 수신되었는지 알 수 없으며 이 점프는 여전히 더 많은 파일이 있는지 확인하기 위해 기다리고 있음을 의미합니다. .
두 번째 버전은 파일 콘텐츠 앞에 페이로드 크기와 함께 HTTP 헤더를 추가하므로 이제 Chrome은 필요한 데이터의 양을 알고 파일 끝에 도달하면 트랜잭션이 완료된 것으로 표시합니다.
nc
HTTP/1.0 200 OK\r\n
HTTP 프로토콜을 통해 콘텐츠를 전송하는 데 필요한 절대 최소값(그렇지는 않지만 허용되는 내용이 매우 관대함)을 구현하는 것과 결합하여 Content-Length
사양에 더 가까운 작업이 추가되었습니다. HTTP 프로토콜에는 자세한 문서가 있으므로 읽어 보시기 바랍니다.RF 카드
편집하다:
- 바운스는 브라우저가 페이지 로드가 완료되지 않았다고 생각하는 것을 의미합니다. 따라서 Chrome은 모든 파일이 있다고 판단할 때까지 계속 호핑합니다.
- URL의 구성 요소를 이해해야 하지만 포트 번호 뒤의 부분은 서버가 제공할 리소스를 가리킵니다. 이 경우 서버는 사용자가 요청한 내용에 신경 쓰지 않고 항상 반환합니다.
some.file
- 이 질문에는 정말 대답할 수 없습니다. 오타였기를 바랍니다
note
.not
답변2
HTTP/1.0에서는 응답에 Content-Length 헤더가 누락된 경우 소켓을 닫아 응답의 끝을 표시합니다. nc
이는 기본적으로 수행되지 않으므로 Chrome(또는 다른 브라우저)은 이 일이 발생할 때까지 "영원히"("플러터") 기다립니다.
첫 번째 명령에 매개변수를 추가하면 -N
제대로 작동합니다.nc
{ echo -ne "HTTP/1.0 200 OK\r\n\r\n"; cat some.file; } | nc -N -l -p 8080
HTTP/1.0에서는 Content-Length 헤더가 필요하지 않습니다(rfc1945 섹션 7.2.2) 본문이 필요하지 않고 비어 있는 경우(섹션 7.2).
URL을 http://IP:8080/
사용하면 브라우저는 IP 및 포트 이후의 모든 항목을 서버로 보내게 됩니다. 이 경우 /
서버에서 기대하는 내용을 나타내는 마지막 항목만 보냅니다. 예제 nc 명령에서는 /
브라우저가 보내는 것(또는 실제로는 다른 것)이 완전히 무시되며 응답은 항상 동일합니다. 따라서 http://IP:8080/hello/world.png
동일한 결과를 사용할 수 있습니다 .