How many headers are allowed in HTTP protocol?
up vote
0
down vote
favorite
I would like to know how many headers are allowed in HTTP protocol. Is there any limit on this?
Is this limit different for Request and Response?
Gone through HTTP RFC, but no luck. Could you please provide me any official document or link about this.
http networking
asked Nov 19 at 9:18
bhanu7k
535
add a comment |
up vote
0
down vote
favorite
I would like to know how many headers are allowed in HTTP protocol. Is there any limit on this?
Is this limit different for Request and Response?
Gone through HTTP RFC, but no luck. Could you please provide me any official document or link about this.
http networking
asked Nov 19 at 9:18
bhanu7k
535
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I would like to know how many headers are allowed in HTTP protocol. Is there any limit on this?
Is this limit different for Request and Response?
Gone through HTTP RFC, but no luck. Could you please provide me any official document or link about this.
http networking
asked Nov 19 at 9:18
bhanu7k
535
I would like to know how many headers are allowed in HTTP protocol. Is there any limit on this?
Is this limit different for Request and Response?
Gone through HTTP RFC, but no luck. Could you please provide me any official document or link about this.
http networking
http networking
asked Nov 19 at 9:18
bhanu7k
535
asked Nov 19 at 9:18
bhanu7k
535
asked Nov 19 at 9:18
bhanu7k
535
asked Nov 19 at 9:18
bhanu7k
535
asked Nov 19 at 9:18
bhanu7k
535
535
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
up vote
2
down vote
accepted
HTTP/1.1 does not define such a limit. See RFC 7230, Section 3.2.5 (https://greenbytes.de/tech/webdav/rfc7230.html#field.limits):
3.2.5. Field Limits
HTTP does not place a predefined limit on the length of each header
field or on the length of the header section as a whole, as described
in Section 2.5. Various ad hoc limitations on individual header field
length are found in practice, often depending on the specific field
semantics.
A server that receives a request header field, or set of fields,
larger than it wishes to process MUST respond with an appropriate 4xx
(Client Error) status code. Ignoring such header fields would increase
the server's vulnerability to request smuggling attacks (Section 9.5).
A client MAY discard or truncate received header fields that are
larger than the client wishes to process if the field semantics are
such that the dropped value(s) can be safely ignored without changing
the message framing or response semantics.
answered Nov 19 at 10:12
Julian Reschke
26.9k45965
add a comment |
up vote
0
down vote
HTTP does not define any limit. But beware that web servers may define the max size of headers they receive.
"Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]." Source: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
answered Nov 19 at 9:25
Ahmad Hijazi
838
1
How is this quote relevant? (apart from being from an obsolete spec)
– Julian Reschke
Nov 19 at 10:08
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
HTTP/1.1 does not define such a limit. See RFC 7230, Section 3.2.5 (https://greenbytes.de/tech/webdav/rfc7230.html#field.limits):
3.2.5. Field Limits
HTTP does not place a predefined limit on the length of each header
field or on the length of the header section as a whole, as described
in Section 2.5. Various ad hoc limitations on individual header field
length are found in practice, often depending on the specific field
semantics.
A server that receives a request header field, or set of fields,
larger than it wishes to process MUST respond with an appropriate 4xx
(Client Error) status code. Ignoring such header fields would increase
the server's vulnerability to request smuggling attacks (Section 9.5).
A client MAY discard or truncate received header fields that are
larger than the client wishes to process if the field semantics are
such that the dropped value(s) can be safely ignored without changing
the message framing or response semantics.
answered Nov 19 at 10:12
Julian Reschke
26.9k45965
add a comment |
up vote
2
down vote
accepted
HTTP/1.1 does not define such a limit. See RFC 7230, Section 3.2.5 (https://greenbytes.de/tech/webdav/rfc7230.html#field.limits):
3.2.5. Field Limits
HTTP does not place a predefined limit on the length of each header
field or on the length of the header section as a whole, as described
in Section 2.5. Various ad hoc limitations on individual header field
length are found in practice, often depending on the specific field
semantics.
A server that receives a request header field, or set of fields,
larger than it wishes to process MUST respond with an appropriate 4xx
(Client Error) status code. Ignoring such header fields would increase
the server's vulnerability to request smuggling attacks (Section 9.5).
A client MAY discard or truncate received header fields that are
larger than the client wishes to process if the field semantics are
such that the dropped value(s) can be safely ignored without changing
the message framing or response semantics.
answered Nov 19 at 10:12
Julian Reschke
26.9k45965
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
HTTP/1.1 does not define such a limit. See RFC 7230, Section 3.2.5 (https://greenbytes.de/tech/webdav/rfc7230.html#field.limits):
3.2.5. Field Limits
HTTP does not place a predefined limit on the length of each header
field or on the length of the header section as a whole, as described
in Section 2.5. Various ad hoc limitations on individual header field
length are found in practice, often depending on the specific field
semantics.
A server that receives a request header field, or set of fields,
larger than it wishes to process MUST respond with an appropriate 4xx
(Client Error) status code. Ignoring such header fields would increase
the server's vulnerability to request smuggling attacks (Section 9.5).
A client MAY discard or truncate received header fields that are
larger than the client wishes to process if the field semantics are
such that the dropped value(s) can be safely ignored without changing
the message framing or response semantics.
answered Nov 19 at 10:12
Julian Reschke
26.9k45965
HTTP/1.1 does not define such a limit. See RFC 7230, Section 3.2.5 (https://greenbytes.de/tech/webdav/rfc7230.html#field.limits):
3.2.5. Field Limits
HTTP does not place a predefined limit on the length of each header
field or on the length of the header section as a whole, as described
in Section 2.5. Various ad hoc limitations on individual header field
length are found in practice, often depending on the specific field
semantics.
A server that receives a request header field, or set of fields,
larger than it wishes to process MUST respond with an appropriate 4xx
(Client Error) status code. Ignoring such header fields would increase
the server's vulnerability to request smuggling attacks (Section 9.5).
A client MAY discard or truncate received header fields that are
larger than the client wishes to process if the field semantics are
such that the dropped value(s) can be safely ignored without changing
the message framing or response semantics.
answered Nov 19 at 10:12
Julian Reschke
26.9k45965
answered Nov 19 at 10:12
Julian Reschke
26.9k45965
answered Nov 19 at 10:12
Julian Reschke
26.9k45965
answered Nov 19 at 10:12
Julian Reschke
26.9k45965
26.9k45965
add a comment |
add a comment |
up vote
0
down vote
HTTP does not define any limit. But beware that web servers may define the max size of headers they receive.
"Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]." Source: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
answered Nov 19 at 9:25
Ahmad Hijazi
838
1
How is this quote relevant? (apart from being from an obsolete spec)
– Julian Reschke
Nov 19 at 10:08
add a comment |
up vote
0
down vote
HTTP does not define any limit. But beware that web servers may define the max size of headers they receive.
"Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]." Source: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
answered Nov 19 at 9:25
Ahmad Hijazi
838
1
How is this quote relevant? (apart from being from an obsolete spec)
– Julian Reschke
Nov 19 at 10:08
add a comment |
up vote
0
down vote
up vote
0
down vote
HTTP does not define any limit. But beware that web servers may define the max size of headers they receive.
"Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]." Source: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
answered Nov 19 at 9:25
Ahmad Hijazi
838
HTTP does not define any limit. But beware that web servers may define the max size of headers they receive.
"Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]." Source: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
answered Nov 19 at 9:25
Ahmad Hijazi
838
answered Nov 19 at 9:25
Ahmad Hijazi
838
answered Nov 19 at 9:25
Ahmad Hijazi
838
answered Nov 19 at 9:25
Ahmad Hijazi
838
838
1
How is this quote relevant? (apart from being from an obsolete spec)
– Julian Reschke
Nov 19 at 10:08
add a comment |
1
How is this quote relevant? (apart from being from an obsolete spec)
– Julian Reschke
Nov 19 at 10:08
1
1
How is this quote relevant? (apart from being from an obsolete spec)
– Julian Reschke
Nov 19 at 10:08
How is this quote relevant? (apart from being from an obsolete spec)
– Julian Reschke
Nov 19 at 10:08
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53371496%2fhow-many-headers-are-allowed-in-http-protocol%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
