HTTP 헤더가 브라우저에 너무 클 수 있습니까?

HTTP 헤더가 브라우저에 너무 클 수 있습니까?

저는 HTTP Content와 HTTP Header를 모두 사용하여 데이터를 주고 받는 AJAX 어플리케이션을 만들고 있습니다.HTTP Header에서 받은 데이터가 너무 커서 브라우저에서 읽을 수 없는 지점이 있습니까?만약 그렇다면 제한은 무엇이며 모든 브라우저에서 동일한 동작입니까?

이론적으로는 HTTP 헤더의 크기에 제한이 없다는 것을 알고 있지만 실제로는 특정 플랫폼, 브라우저 또는 클라이언트 컴퓨터나 기계에 설치된 특정 소프트웨어에서 문제가 발생할 수 있습니다.HTTP 헤더를 안전하게 사용할 수 있도록 가이드라인을 좀 더 알아보고 있습니다.다시 말해, 라인으로 들어오는 잠재적인 문제 없이 추가 데이터를 전송하기 위해 HTTP 헤더를 사용할 수 있는 범위는?

---

감사합니다, 이 질문에 대한 모든 의견을 주셔서 대단히 감사하고 흥미로웠습니다.토마스의 대답은 현상금을 받았지만 존 한나의 대답은 대리에 대한 좋은 점을 제기했습니다.

단답형:

동일한 동작: 아니오

인기 브라우저에서 발견되는 최저 한도:

• 헤더당 10KB
• 하나의 응답에서 모든 헤더에 대해 256KB입니다.

Mac OS X 10.6.4를 실행하는 MacBook의 테스트 결과:

가장 큰 응답이 로드되었으며, 모든 데이터가 하나의 헤더에 포함됩니다.

• 오페라 10: 150MB
• 사파리 5: 20MB
• IE 6 via Wine: 10MB
• 크롬 5: 250KB
• Firefox 3.6: 10KB

참고 Opera, Safari 및 IE의 엄청난 대형 헤더를 로드하는 데 몇 분이 걸렸습니다.

Chrome 참고 사항:실제 제한은 전체 HTTP 헤더에 대해 256KB인 것 같습니다.오류 메시지가 나타납니다. "Error 325(net::ER_RESPONGESS_HEADERS_TOO_BIG): 알 수 없는 오류입니다."

Firefox 참고: 여러 헤더를 통해 100MB의 데이터를 전송할 때는 10,000개 이상의 헤더를 분할하면 됩니다.

나의 결론:모든 인기 브라우저를 지원하려면 헤더당 10KB가 제한이고 모든 헤더를 모두 합하면 256KB인 것 같습니다.

내 PHP 코드는 다음과 같은 응답을 생성하는 데 사용되었습니다.

<?php

ini_set('memory_limit', '1024M');
set_time_limit(90);
$header = "";

$bytes = 256000;

for($i=0;$i<$bytes;$i++) {
    $header .= "1";
}

header("MyData: ".$header);
/* Firfox multiple headers
for($i=1;$i<1000;$i++) {
    header("MyData".$i.": ".$header);
}*/

echo "Length of header: ".($bytes / 1024).' kilobytes';

?>

실제로 프록시가 특정 헤더를 전달하지 못하도록 금지하는 규칙이 있지만(사실 수정할 수 있는 매우 명확한 규칙과 나중에 추가된 새로운 헤더를 수정할 수 있는지 여부에 대해 프록시에 알리는 방법에 대해서도), 이는 "투명" 프록시에만 적용되며 모든 프록시가 투명하지는 않습니다.특히 일부는 의도적인 보안 관행으로 이해하지 못하는 헤더를 삭제하기도 합니다.

또한, 실제로 일부 사람들은 잘못 행동하기도 합니다 (비록 상황이 예전보다 훨씬 나아졌지만).

따라서 분명한 핵심 헤더 외에 서버에서 클라이언트로 전달되는 데 의존할 수 있는 헤더 정보의 양은 0입니다.

이것은 헤더가 잘 사용되는 것에 의존해서는 안 되는 이유 중 하나일 뿐입니다(예: 클라이언트가 캐시해야 할 것에 대한 요청을 반복하거나, 인증 헤더의 명백한 경우(보안 실패 원칙 하에서)를 제외하고는 서버가 전체 엔티티를 전송할 준비가 되어 있어야 합니다).

두 가지.

우선 브라우저에 점점 더 큰 헤더를 제공하는 테스트를 실행하고 작동하지 않는 숫자에 도달할 때까지 기다리는 것이 어떨까요?각 브라우저에서 한 번만 실행하면 됩니다.그것이 이것을 알아낼 수 있는 가장 확실한 방법입니다.비록 완전히 포괄적이지는 않더라도 최소한 몇 가지 실제적인 숫자는 사용자의 상당 부분을 차지할 것입니다.

둘째, 모두가 이것이 나쁜 생각이라고 말하는 것에 동의합니다.한계에 도달하는 것에 대해 정말로 걱정한다면 다른 해결책을 찾는 것은 어렵지 않을 것입니다.모든 브라우저에서 테스트를 수행하더라도 여전히 걱정해야 할 방화벽 등이 있으며, 모든 조합을 테스트할 수 있는 방법은 절대 없습니다(그리고 이전에 이 작업을 수행한 사람은 아무도 없을 것이라고 거의 확신합니다)모든 경우에 대해 엄격한 제한을 받을 수는 없을 것입니다.

이론적으로는 이 모든 것이 잘 해결될 것입니다. 하지만 나중에 이렇게 결정한다면 당신의 엉덩이를 물어뜯는 가장자리 케이스가 하나 생길 수도 있습니다.

TL;DR: 이건 나쁜 생각입니다.수고를 덜고 해결책 대신 진정한 해결책을 찾으세요.

---

편집: 여러 종류의 소스에서 요청이 올 수 있다고 하니, 요청 헤더에 소스만 지정하고 데이터를 전부 본문에 포함하는 것은 어떨까요?어떤 종류의 것을 가지세요.Source아니면ClientType요청이 발생하는 위치를 지정하는 헤더의 필드입니다.브라우저에서 나온 것이라면 본문에 HTML을 포함하고, PHP 애플리케이션에서 나온 것이라면 PHP에 특화된 것을 넣어두는 등의 방법을 사용합니다.필드가 비어 있으면 추가 데이터를 전혀 추가하지 않습니다.

HTTP/1.1에 대한 RFC는 분명히 헤더나 본문의 길이를 제한하지 않습니다.

이 페이지에 따르면 IE를 제외한 현대 브라우저(Firefox, Safari, Opera)는 매우 긴 URI(https://web.archive.org/web/20191019132547/https ://boutell.com/newfaq/misc/urllength.html )를 처리할 수 있습니다.헤더를 받는 것과 다르다는 것을 알지만, 적어도 그들이 거대한 HTTP 요청을 생성하고 보낼 수 있다는 것을 보여줍니다(아마도 무제한 길이).

브라우저에 제한이 있다면 사용 가능한 메모리의 크기나 변수 유형의 제한 등이 될 것입니다.

이론적으로는 브라우저에서 보낼 수 있는 데이터의 양에 제한이 없습니다.이것은 거의 웹 페이지 본문에 있을 수 있는 콘텐츠의 양에 제한이 있다는 것을 말하는 것과 같습니다.

가능하면 문서 본문을 통해 데이터를 전송합니다.안전한 쪽으로 가기 위해서는 데이터를 여러 개로 분할하여 로드할 수 있는 패스가 여러 개가 되도록 하는 것이 좋습니다.

언급URL : https://stackoverflow.com/questions/3326210/can-http-headers-be-too-big-for-browsers