2주차 Quiz & Answer

[LEEJaeHyeok97]

2주차 퀴즈 여기에 올려주세요!

답변은 <details></details> 태그로 작성하거나 대댓글로 작성 후 hide 처리!

[LEEJaeHyeok97]

프래그먼트(#)는 서버에 전달되지 않는다. 이것의 함의는 무엇일까

[kkatalchae]

URL 파라미터로 데이터를 전달할 때 공백이나 한글, 특정 특수문자가 포함되면 왜 서버에서 오류가 발생하거나 값이 깨지는 이유와 해결 방법

[023-dev]

아까 언급이 있었던 RFC 2396 → RFC 3986 주요 변경점을 공유드립니다.

Details

1. IPv6 주소를 host에 넣을 때 대괄호를 명확히 사용

기존에는 URL에서 host 부분에 IPv6를 표현하는 방식이 다소 덜 정교했지만, RFC 3986에서는 이를 더 명확히 정리했습니다.

• IPv4 예시: http://192.168.0.1/index.html
• IPv6 예시: http://[2001:db8::1]/index.html
  중요한 점은 IPv6 주소에는 :가 많이 포함되기 때문에, 그대로 쓰면 포트 구분자와 혼동될 수 있다는 점입니다.
• 잘못 해석될 수 있는 형태: http://2001:db8::1/index.html
• RFC 3986이 의도한 명확한 형태: http://[2001:db8::1]/index.html
  즉, 대괄호는 IPv6 리터럴을 host에서 안전하게 구분하기 위한 장치입니다.

그리고 [와 ]를 authority 안에서 IP 리터럴 구분자 용도로만 의미 있게 사용하도록 정리했습니다.

• 올바른 예: http://[2001:db8::1]:8080/path
• 잘못된 예: http://example.com/[test]
  두 번째처럼 path 쪽에 대괄호 문자를 그대로 쓰려면 보통 인코딩이 필요합니다.
  즉, 대괄호를 예약어의 의미로 더 명확해졌습니다.

---

2. IPv4 주소도 더 엄격하게 검증

RFC 3986은 IPv4 각 옥텟이 0~255 범위여야 한다는 점을 더 분명히 했습니다.

• 올바른 예: http://192.168.0.10
• 잘못된 예: http://999.168.0.10
  즉, 예전보다 문법적으로 실제 IPv4 형식에 더 맞게 제한했습니다.

참고: Changes from RFC 2396

[LEEJaeHyeok97]

내용 좋네요? ㄷㄷ

[023-dev]

찾아보니 RFC 3986 보다 업그레이드된 메이저 버전이 2개 정도 더 있더라구요.

[LEEJaeHyeok97]

역시 책이 오래된 내용을 담고 있을 수 밖에 없으니.. 업데이트는 따로 찾아야 되네요