You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Boris Pruessmann (Created) (JIRA)" <ji...@apache.org> on 2012/02/24 16:28:49 UTC
[jira] [Created] (SLING-2426) SlingSafeMethodsServlet's default
HEAD implementation not completely RFC compliant
SlingSafeMethodsServlet's default HEAD implementation not completely RFC compliant
----------------------------------------------------------------------------------
Key: SLING-2426
URL: https://issues.apache.org/jira/browse/SLING-2426
Project: Sling
Issue Type: Bug
Components: Servlets
Affects Versions: Servlets Get 2.1.2
Reporter: Boris Pruessmann
RFC 2616 states: "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response."
The current implementation of the SlingSafeMethodsServlet does not guarantee what's stated above - if the GET call's response gets too big, the servlet engine might switch to chunked transfer. However, the HEAD call returns a valid Content-Length header no matter what, resulting in HEAD returning different headers than the corresponding GET call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2426) SlingSafeMethodsServlet's default
HEAD implementation not completely RFC compliant
Posted by "Roy T. Fielding (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13216128#comment-13216128 ]
Roy T. Fielding commented on SLING-2426:
----------------------------------------
There is no need to fix this. Both Content-Length and Transfer-Encoding are subject to removal or change at any hop in the response chain. They are message framing headers, not information about the resource or its representation, and thus are not subject to the requirement above. It will be (or has alreade been) clarified in HTTPbis.
> SlingSafeMethodsServlet's default HEAD implementation not completely RFC compliant
> ----------------------------------------------------------------------------------
>
> Key: SLING-2426
> URL: https://issues.apache.org/jira/browse/SLING-2426
> Project: Sling
> Issue Type: Bug
> Components: Servlets
> Affects Versions: API 2.2.0
> Reporter: Boris Pruessmann
>
> RFC 2616 states: "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response."
> The current implementation of the SlingSafeMethodsServlet does not guarantee what's stated above - if the GET call's response gets too big, the servlet engine might switch to chunked transfer. However, the HEAD call returns a valid Content-Length header no matter what, resulting in HEAD returning different headers than the corresponding GET call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2426) SlingSafeMethodsServlet's default
HEAD implementation not completely RFC compliant
Posted by "Roy T. Fielding (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218849#comment-13218849 ]
Roy T. Fielding commented on SLING-2426:
----------------------------------------
It is okay to provide either one if you know them in advance. You just can't rely on receiving them because they could be removed or replaced along the path (and that path includes the internals of the origin server). For example, an origin server might internally cork a response body on a GET just long enough to learn the length and hence be able to send Content-Length dynamically, whereas that would be impossible in response to HEAD.
> SlingSafeMethodsServlet's default HEAD implementation not completely RFC compliant
> ----------------------------------------------------------------------------------
>
> Key: SLING-2426
> URL: https://issues.apache.org/jira/browse/SLING-2426
> Project: Sling
> Issue Type: Bug
> Components: Servlets
> Affects Versions: API 2.2.0
> Reporter: Boris Pruessmann
>
> RFC 2616 states: "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response."
> The current implementation of the SlingSafeMethodsServlet does not guarantee what's stated above - if the GET call's response gets too big, the servlet engine might switch to chunked transfer. However, the HEAD call returns a valid Content-Length header no matter what, resulting in HEAD returning different headers than the corresponding GET call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2426) SlingSafeMethodsServlet's default
HEAD implementation not completely RFC compliant
Posted by "Felix Meschberger (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215801#comment-13215801 ]
Felix Meschberger commented on SLING-2426:
------------------------------------------
Hmm, the problematic sentence is "might switch to chunked transfer". Not having checked any spec or such, but how would we be able to know whether the servlet container might switch or not ?
Off the top of my head, I would assume that chunked is switched on if there is no Content-Length header but the response gets committed.
But how do we do chunked transfer without a body stating "that's it" ?
> SlingSafeMethodsServlet's default HEAD implementation not completely RFC compliant
> ----------------------------------------------------------------------------------
>
> Key: SLING-2426
> URL: https://issues.apache.org/jira/browse/SLING-2426
> Project: Sling
> Issue Type: Bug
> Components: Servlets
> Affects Versions: API 2.2.0
> Reporter: Boris Pruessmann
>
> RFC 2616 states: "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response."
> The current implementation of the SlingSafeMethodsServlet does not guarantee what's stated above - if the GET call's response gets too big, the servlet engine might switch to chunked transfer. However, the HEAD call returns a valid Content-Length header no matter what, resulting in HEAD returning different headers than the corresponding GET call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SLING-2426) SlingSafeMethodsServlet's default
HEAD implementation not completely RFC compliant
Posted by "Felix Meschberger (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger resolved SLING-2426.
--------------------------------------
Resolution: Not A Problem
Assignee: Felix Meschberger
So I think we can safely resolve this as not being a problem and thus to not do anything about it.
> SlingSafeMethodsServlet's default HEAD implementation not completely RFC compliant
> ----------------------------------------------------------------------------------
>
> Key: SLING-2426
> URL: https://issues.apache.org/jira/browse/SLING-2426
> Project: Sling
> Issue Type: Bug
> Components: Servlets
> Affects Versions: API 2.2.0
> Reporter: Boris Pruessmann
> Assignee: Felix Meschberger
>
> RFC 2616 states: "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response."
> The current implementation of the SlingSafeMethodsServlet does not guarantee what's stated above - if the GET call's response gets too big, the servlet engine might switch to chunked transfer. However, the HEAD call returns a valid Content-Length header no matter what, resulting in HEAD returning different headers than the corresponding GET call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SLING-2426) SlingSafeMethodsServlet's default
HEAD implementation not completely RFC compliant
Posted by "Boris Pruessmann (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218082#comment-13218082 ]
Boris Pruessmann commented on SLING-2426:
-----------------------------------------
Thanks for clarifying this, Roy. This makes total sense to me.
In that case, is providing a Content-Length actually correct if message framing headers are not subject to the requirement above? I am not asking for any code change here, just trying to get the implementation on my side right.
> SlingSafeMethodsServlet's default HEAD implementation not completely RFC compliant
> ----------------------------------------------------------------------------------
>
> Key: SLING-2426
> URL: https://issues.apache.org/jira/browse/SLING-2426
> Project: Sling
> Issue Type: Bug
> Components: Servlets
> Affects Versions: API 2.2.0
> Reporter: Boris Pruessmann
>
> RFC 2616 states: "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response."
> The current implementation of the SlingSafeMethodsServlet does not guarantee what's stated above - if the GET call's response gets too big, the servlet engine might switch to chunked transfer. However, the HEAD call returns a valid Content-Length header no matter what, resulting in HEAD returning different headers than the corresponding GET call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (SLING-2426) SlingSafeMethodsServlet's default
HEAD implementation not completely RFC compliant
Posted by "Boris Pruessmann (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SLING-2426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boris Pruessmann updated SLING-2426:
------------------------------------
Affects Version/s: (was: Servlets Get 2.1.2)
API 2.2.0
> SlingSafeMethodsServlet's default HEAD implementation not completely RFC compliant
> ----------------------------------------------------------------------------------
>
> Key: SLING-2426
> URL: https://issues.apache.org/jira/browse/SLING-2426
> Project: Sling
> Issue Type: Bug
> Components: Servlets
> Affects Versions: API 2.2.0
> Reporter: Boris Pruessmann
>
> RFC 2616 states: "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response."
> The current implementation of the SlingSafeMethodsServlet does not guarantee what's stated above - if the GET call's response gets too big, the servlet engine might switch to chunked transfer. However, the HEAD call returns a valid Content-Length header no matter what, resulting in HEAD returning different headers than the corresponding GET call.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira