You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org> on 2005/07/08 18:07:11 UTC
[jira] Created: (TAPESTRY-389) asset service: send 304 status code when appropriate
asset service: send 304 status code when appropriate
----------------------------------------------------
Key: TAPESTRY-389
URL: http://issues.apache.org/jira/browse/TAPESTRY-389
Project: Tapestry
Type: Improvement
Components: Framework
Versions: 4.0
Reporter: Howard M. Lewis Ship
Fix For: 4.0
With the proliferation of files (especially JavaScript libraries) being vended out by the asset service, it should be as efficient as possible.
The asset service should be sending 304 responses when the client already has an asset file.
Note that with the md5 checksum integrated into the asset URI, the URI will change anytime the content of the file changes. This means *any* conditional get (meaning that the client has a version of the file and wants to ensure that its up-to date) should return a 304 response code.
Not Modified 304
If the client has done a conditional GET and access is allowed, but the document has not been modified since the date and time specified in If-Modified-Since field, the server responds with a 304 status code and does not send the document body to the client.
Response headers are as if the client had sent a HEAD request, but limited to only those headers which make sense in this context. This means only headers that are relevant to cache managers and which may have changed independently of the document's Last-Modified date. Examples include Date , Server and Expires .
The purpose of this feature is to allow efficient updates of local cache information (including relevant metainformation) without requiring the overhead of multiple HTTP requests (e.g. a HEAD followed by a GET) and minimizing the transmittal of information already known by the requesting client (usually a caching proxy).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Commented: (TAPESTRY-389) asset service: send 304 status code when appropriate
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-389?page=comments#action_12315323 ]
Howard M. Lewis Ship commented on TAPESTRY-389:
-----------------------------------------------
Need to set the Last-Modified header in the response, this will cause the client to send an If-Modified-Since header in the request.
> asset service: send 304 status code when appropriate
> ----------------------------------------------------
>
> Key: TAPESTRY-389
> URL: http://issues.apache.org/jira/browse/TAPESTRY-389
> Project: Tapestry
> Type: Improvement
> Components: Framework
> Versions: 4.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Fix For: 4.0
>
> With the proliferation of files (especially JavaScript libraries) being vended out by the asset service, it should be as efficient as possible.
> The asset service should be sending 304 responses when the client already has an asset file.
> Note that with the md5 checksum integrated into the asset URI, the URI will change anytime the content of the file changes. This means *any* conditional get (meaning that the client has a version of the file and wants to ensure that its up-to date) should return a 304 response code.
> Not Modified 304
> If the client has done a conditional GET and access is allowed, but the document has not been modified since the date and time specified in If-Modified-Since field, the server responds with a 304 status code and does not send the document body to the client.
> Response headers are as if the client had sent a HEAD request, but limited to only those headers which make sense in this context. This means only headers that are relevant to cache managers and which may have changed independently of the document's Last-Modified date. Examples include Date , Server and Expires .
> The purpose of this feature is to allow efficient updates of local cache information (including relevant metainformation) without requiring the overhead of multiple HTTP requests (e.g. a HEAD followed by a GET) and minimizing the transmittal of information already known by the requesting client (usually a caching proxy).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Closed: (TAPESTRY-389) asset service: send 304 status code when appropriate
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-389?page=all ]
Howard M. Lewis Ship closed TAPESTRY-389:
-----------------------------------------
Resolution: Fixed
> asset service: send 304 status code when appropriate
> ----------------------------------------------------
>
> Key: TAPESTRY-389
> URL: http://issues.apache.org/jira/browse/TAPESTRY-389
> Project: Tapestry
> Type: Improvement
> Components: Framework
> Versions: 4.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Fix For: 4.0
>
> With the proliferation of files (especially JavaScript libraries) being vended out by the asset service, it should be as efficient as possible.
> The asset service should be sending 304 responses when the client already has an asset file.
> Note that with the md5 checksum integrated into the asset URI, the URI will change anytime the content of the file changes. This means *any* conditional get (meaning that the client has a version of the file and wants to ensure that its up-to date) should return a 304 response code.
> Not Modified 304
> If the client has done a conditional GET and access is allowed, but the document has not been modified since the date and time specified in If-Modified-Since field, the server responds with a 304 status code and does not send the document body to the client.
> Response headers are as if the client had sent a HEAD request, but limited to only those headers which make sense in this context. This means only headers that are relevant to cache managers and which may have changed independently of the document's Last-Modified date. Examples include Date , Server and Expires .
> The purpose of this feature is to allow efficient updates of local cache information (including relevant metainformation) without requiring the overhead of multiple HTTP requests (e.g. a HEAD followed by a GET) and minimizing the transmittal of information already known by the requesting client (usually a caching proxy).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
[jira] Assigned: (TAPESTRY-389) asset service: send 304 status code when appropriate
Posted by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org>.
[ http://issues.apache.org/jira/browse/TAPESTRY-389?page=all ]
Howard M. Lewis Ship reassigned TAPESTRY-389:
---------------------------------------------
Assign To: Howard M. Lewis Ship
> asset service: send 304 status code when appropriate
> ----------------------------------------------------
>
> Key: TAPESTRY-389
> URL: http://issues.apache.org/jira/browse/TAPESTRY-389
> Project: Tapestry
> Type: Improvement
> Components: Framework
> Versions: 4.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Fix For: 4.0
>
> With the proliferation of files (especially JavaScript libraries) being vended out by the asset service, it should be as efficient as possible.
> The asset service should be sending 304 responses when the client already has an asset file.
> Note that with the md5 checksum integrated into the asset URI, the URI will change anytime the content of the file changes. This means *any* conditional get (meaning that the client has a version of the file and wants to ensure that its up-to date) should return a 304 response code.
> Not Modified 304
> If the client has done a conditional GET and access is allowed, but the document has not been modified since the date and time specified in If-Modified-Since field, the server responds with a 304 status code and does not send the document body to the client.
> Response headers are as if the client had sent a HEAD request, but limited to only those headers which make sense in this context. This means only headers that are relevant to cache managers and which may have changed independently of the document's Last-Modified date. Examples include Date , Server and Expires .
> The purpose of this feature is to allow efficient updates of local cache information (including relevant metainformation) without requiring the overhead of multiple HTTP requests (e.g. a HEAD followed by a GET) and minimizing the transmittal of information already known by the requesting client (usually a caching proxy).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org