nginx 요청 url인 긴경우 에러 해결하기

# nginx 웹서버 요청시 아래와 같이 아주 긴 문자열을 포함시켜 요청을 하게 되면
# 요청이 제대로 전달되지 않는 문제가 발생하는 경우가 생긴다.
http://server.ysoftman.com/test?param1=aaaaa ... zzzzz (1000자 이상)

# nginx 에서 set 으로 사용자 변수(로그필터링을 위해 변수를 사용하는등)를
# 사용하는 경우 다음과 같은 에러가 발생하기도 한다.
unsing uninitialized 'myvar1' ... variable while logging request....

# 참고 http://nginx.org/en/docs/debugging_log.html
# nginx 빌드시 다음과 같이 디버그 사용 옵션을 준다.
./configure --with-debug

# 설정에서 로그 레벨을 debug 로 명시하면
# nginx 에서 발생하는 구체적인 에러를 볼 수 있다.
error_log /path/to/log debug;

# debug 로깅으로 다음과 같은 에러 메시지가 찍힌다.
client exceeded http2_max_field_size limit while processing HTTP/2 connection

# 참고 http://nginx.org/en/docs/http/ngx_http_v2_module.html#directives
# http2 헤더 와 필드 값을 늘려 줘야 한다.
http2_max_field_size 16k;  # default 4k
http2_max_header_size 32k;  # default 16k

# 그리고 다음과 같이 URI 이 너무 길다는 에러 응답을 받는다면
414 Request-URI Too Large
# 참고 http://nginx.org/en/docs/http/ngx_http_core_module.html#large_client_header_buffers
# 다음과 같이 클라이언트 헤더 버퍼를 늘려주자.
large_client_header_buffers 4 8k;

# 414 에러가 apache httpd 에서 발생한다면 LimitRequestLine 설정을 늘려 주자.

# 참고 http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline

LimitRequestLine 16000 # default 8190

chrome http 301 응답 캐시 삭제

chrome(크롬) 에서 해당 사이트 요청에 301(permanent redirect) 응답을 받는 경우 캐시하여 계속 리다이렉트 하게된다.

301 은 영구적으로 사이트가 이동 되었다는 의미로 사용 되기 때문에 한번 301 응답을 받으면 클라이언트(브라우저는) 해당 사이트의 리다이렉트 값을 캐싱하여 웹서버 확인 없이 계속 옮겨진 사이트로 리다이렉트 한다.

웹서버는 영구적으로 사이트가 옮겨 졌다면 301 응답을 주면 되지만 임시로 옮겨 졌다면
302 (temporarily moved)를 사용하여 클라이언트가 계속 웹서버에 확인할 수 있도록 해야 한다.

크롬에서 아래 설정에서 301 응답 캐시를 지워주면 다시 해당사이트에 요청을 하여 확인 할 수 있다.

chrome Settings(설정) -> Show advanced settings(고급) ->  Privacy(개인정보 및 보안) -> Click Clear browsing data (인터넷 사용기록 삭제) -> Cached images and files (캐시된 이미지 또는 파일) 체크 후 삭제

웹서비스 robot.txt human.txt

웹서비스에서 web crawler 같은 로봇들의 활동을 제어하는 방안으로 robot.txt 을 루르 경로에 만들어 두고 사용한다.(권고 사항으로 강제되지는 않는다)

예)

https://www.google.com/robots.txt

http://search.naver.com/robots.txt

http://search.daum.net/robots.txt

robot.txt 과 같은 방법으로 웹서비스에 기여한 사람들을 human.txt 파일로 만들어 두기도 한다.

형식은 http://humanstxt.org/Standard.html

예)

https://www.google.com/humans.txt

https://search.naver.com/humans.txt

nginx http2 brotli 사용하기

nginx 에서 http2 를 적용 후 기존 gzip 을 대체하는 brotli 를 압축을 사용할 수 있다.
우선 nginx 용으로 만들어진 모듈을 다운받는다.

# deps 디렉토리가 brotli (https://github.com/google/brotli) 를 바라보고 있어
# clone 시 --recursive 옵션을 사용하여 brotli 까지 모두 다운 받아야 한다.
git clone --recursive https://github.com/google/ngx_brotli

# nginx 빌드시 brotli 모듈을 추가해 빌드한다.

--add-module=/home/ysoftman/ngx_brotli

# nginx.conf 설정에서 brotli 사용
# MIME 설명
# https://developer.mozilla.org/ko/docs/Web/HTTP/Basics_of_HTTP/MIME_types

http {

    brotli on;  # on-the-fly 로 요청마다 brotli 압축

    brotli_static on;  # 미리 압축해논 .br 파일을 사용

    brotli_types *; # on-the-fly 때 압축할 MIME 타입 설정

}

# 크롬 브라우저는 https(http2) 요청시 brotli(br) 이 지원되어 다음과 같이 gzip 과 함께 br 을 명시한다.

accept-encoding:gzip, deflate, br

# nginx 는 https(http2) 의 요청에 대해서 다음과 같이 br 로 인코딩하여 응답한다.

content-encoding:br

content-type:text/html

date:Mon, 26 Jun 2017 06:03:57 GMT

etag:W/"5950a3c7-264"

last-modified:Mon, 26 Jun 2017 06:03:51 GMT

server:nginx

status:200

# 참고

# 이미 브라우저가 해당 리소스(ex. html 파일)를 가지고 있다면 캐쉬되어

# 304(not modified, 서버의 리소스가 클라가 캐시와 비교해 변경된것이 없다.)

# 응답을 주면 다음과 같이  "content-encoding:br" 명시될 필요가 없다.

date:Mon, 26 Jun 2017 06:19:00 GMT

etag:"59506b41-264"

last-modified:Mon, 26 Jun 2017 02:02:41 GMT

server:nginx

status:304

http2 에서의 keep-alive

http1.1 의 경우
request 헤더에 다음과 같이 "keep-alive" 를 명시하여 웹서버에 요청하면
Connection:keep-alive

웹서버가 keep-alive 기능을 지원한다면 response 헤더에 다음과 같이 설정된다.
Connection:Keep-Alive

그런데 http2 의 경우 connection 관련 헤더 필드는 따로 명시하지 않는다고 한다.
http://httpwg.org/specs/rfc7540.html#n-connection-specific-header-fields

curl 유용한 옵션

# wget
# 예전에는 웹에 올라온 파일을 콘솔환경에서 다운받을때 wget 명령어를 주로 사용했다.
# 다음과 같이 다운받을 대상 url 만 명시하면 파일이 다운로드되는 형식이다.
wget http://ysoftman.com/ysoftman.tar.gz

# ysoftman.out 파일로 내용 저장
wget -O ysoftman.out http://ysoftman.com/ysoftman.html

# -O 뒤 - 주면 stdout 으로 다운받은 내용을 강제 출력한다.
wget -O - http://ysoftman.com/ysoftman.html

# curl
# 언제부터인가 wget 대신 curl 을 많이 사용하게 된다.
# 보통 curl 특정 특정 웹의 html 응답을 파악할때 사용한다.
curl http://www.google.com

# curl 로 파일을 받을때는 -O (대문자 o) 옵션을 주면 된다.
curl -O http://ysoftman.com/ysoftman.tar.gz

# -o 로 파일을 명시할 수 도 있다.
# -o- 로 -를 주면 stdout 으로 다운받은 내용을 강제 출력한다.
curl -o ysoftman.out http://ysoftman.com/ysoftman.tar.gz

# 만약 다운받은 파일이 예상했던 크기보다 작다면 -v 옵션으로 다운로드 과정을 살펴보자.
curl -Ov http://ysoftman.com/ysoftman.tar.gz

# HTTP/1.1 302 (redirect) 로 해당 파일을 redirect 하여 다운로드를 받아야한다면
# -L 옵션으로 redirect 를 따라가서 파일을 다운로드 받을 수 있다.
# 참고로 wget 은 별도의 옵션없이 redirect 처리가 된다.
curl -OLv http://ysoftman.com/ysoftman.tar.gz

# POST 방식으로 data 를 요청할때
# -X POST 방식(-d 가 있으면 생략가능)
# -d 데이터, 파일을 사용할때는 @파일명
# --trace-ascii /dev/stdout 표준 출력을 트레이스하여 데이터 내용을 확인할 수 있다.
curl -v -X POST http://ysoftman.com -d "ysoftman" --trace-ascii /dev/stdout

# 파일 업로드

# -F 멀티파트 폼데이터로 파일 전송

# zzz : form 필드에서 aaa.txt 데이터가 들어갈 위치(키)

# @전송할 파일명,

curl -X POST -F 'zzz=@./aaa.txt' http://ysoftman.com/upload

# -s, --silent 진행상태 에러메시지등 표시하지 않기
curl -s http://www.google.co.kr

# -i --include 헤더와 바디 보기
curl -i http://www.google.co.kr

# -I, --head 헤더만 보기
curl -I http://www.google.co.kr

# -I 는 기본적으로 HEAD 커맨드를 사용한다.
# GET 요청시에서의 헤더만 보기
curl -I -X GET http://www.google.co.kr

# -L 302 redirect 하여 응답헤더 보기
curl -IL http://www.google.com

# -D filename 헤더 덤프해서 보기(- 로 파일명을 안줄 수 있다)
curl -D - http://www.google.co.kr

# -H, --header 요청헤더 설정(헤더는 대소문자 구분하지 않는다.)
curl -I -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.142 Safari/537.36' -H 'Accept-Encoding: br' https://www.google.co.kr

# 응답 데이터 크기만 보기
curl -s http://www.google.co.kr -w '%{size_download}\n' -o /dev/null

# 응답 상태 코드만 보기
curl -s http://www.google.co.kr -w '%{http_code}\n' -o /dev/null

# elapsed(경과시간) 측정

curl http://www.google.co.kr -w "\n\nConnect time: %{time_connect} Time to first byte: %{time_starttransfer} Total time: %{time_total}"

# https + http2 요청
curl -sI http://www.google.co.kr --http2

# https + http1.1 요청
curl -sI http://www.google.co.kr --http1.1