Mercurial > p > roundup > code
view website/issues/html/keyword.item.html @ 8185:e84d4585b16d
fix(web): issue2551356. Add etag header for not-modified (304) request.
When a 304 is returned to a conditional request for a static file,
print an ETag for the response.
ETag was always sent with a 200 response.
This also adds initial support for if-none-match conditional requests
for static files.
Changes:
Refactors the if-modified-since code out to a method.
It moves a file stat call from serve_static_file to _serve_file
so that an etag can be generated by both serve_static_file and
serve_file which call _serve_file.
Tests added. This does not test the codepath where serve_file pulls
content from the database rather than from a local file on disk.
Test mocking _serve_file changed to account for 5th argument to serve_file
BREAKING CHANGE:
function signature for client.py-Client::_serve_file() now has 5 not 4
parameters (added etag param). Since this is a "hidden" method I am
not too worried about it.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Tue, 10 Dec 2024 16:06:13 -0500 |
| parents | eff9c5435acc |
| children |
line wrap: on
line source
<!-- dollarId: keyword.item,v 1.3 2002/05/22 00:32:34 richard Exp dollar--> <tal:block metal:use-macro="templates/page/macros/icing"> <title metal:fill-slot="head_title" i18n:translate="">Keyword editing - <span i18n:name="tracker" tal:replace="config/TRACKER_NAME" /></title> <span metal:fill-slot="body_title" tal:omit-tag="python:1" i18n:translate="">Keyword editing</span> <td class="content" metal:fill-slot="content"> <table class="otherinfo" tal:define="keywords db/keyword/list" tal:condition="keywords"> <tr><th colspan="4" class="header" i18n:translate="">Existing Keywords</th></tr> <tr tal:repeat="start python:range(0, len(keywords), 4)"> <td width="25%" tal:define="batch python:utils.Batch(keywords, 4, start)" tal:repeat="keyword batch"> <a tal:attributes="href string:keyword${keyword/id}" tal:content="keyword/name">keyword here</a> </td> </tr> <tr> <td colspan="4" style="border-top: 1px solid gray" i18n:translate=""> To edit an existing keyword (for spelling or typing errors), click on its entry above. </td> </tr> </table> <p class="help" tal:condition="not:context/id" i18n:translate=""> To create a new keyword, enter it below and click "Submit New Entry". </p> <form method="POST" onSubmit="return submit_once()" enctype="multipart/form-data" tal:attributes="action context/designator"> <table class="form"> <tr> <th i18n:translate="">Keyword</th> <td tal:content="structure python:context.name.field(size=60)">name</td> </tr> <tr> <th class="required" i18n:translate="">Description:</th> <td tal:content="structure python:context.description.field(size=60)">description</td> </tr> <tr> <td tal:condition="not:context/id"> <tal:comment tal:replace="nothing"> If we get here and do not have an id, we are creating a new keyword. It would be nice to provide some mechanism to determine the preferred state of the "Continue adding keywords" checkbox. By default I have it enabled. </tal:comment> <input type="checkbox" id="continue_new_keyword" name="__redirect_to" tal:attributes="value string:${request/base}${request/env/PATH_INFO}?@template=item; checked python:True" /> <label for="continue_new_keyword" i18n:translate="">Continue adding keywords.</label> </td> </tr> <tr> <td> <input type="hidden" name="@required" value="name"> <input type="hidden" name="@template" value="item"> </td> <td colspan=3 tal:content="structure context/submit"> submit button will go here </td> </tr> </table> </form> </td> </tal:block>
