Monday, November 24, 2014

Re: Obtaining content from Git

On 2014-11-24 11:49, martin f krafft wrote:
> also sprach Tim Chase <django.users@tim.thechases.com> [2014-11-24
> 11:19 +0100]:
> > urlpatterns = patterns('',
> > url(r'^blob/([0-9a-f]{40})/$',
> > 'myapp.views.render_blob', ...), )
>
> … this is straight-forward, thanks. I'd probably try not to expose
> the SHAs to the user but request from the Git library a blob
> identified by a path such as /path/to/file which the Git
> library should then map to the blob, given a treeish to use as
> a base (e.g. 'master', this could come from config).

Django certainly gives you the flexibility to do both/either. You
can even do things like

url(r'branch/(?P<branch>[^/]*)(?P<filename>.*)', 'myapp.views.render_branch_file', ...)

and then in your views.py

def render_branch_file(request, branch, file_name):
data = some_git_lib.get_file_from_branch(branch, file_name)
...

You might need to tighten up those regular expressions in the urls.py
a bit, or sanitize them in the view to ensure that they don't allow
access to files outside the git tree (you might also want to prevent
access to the .git subdirectory)

> > In theory, you could also set the cache control headers in the
> > response so that they're ludicrously far in the future (assuming
> > you don't plan to change your my_template.html) because the blob
> > shouldn't ever change without having a different SHA1.
>
> Two problems I see with this:
>
> 1. If the SHA is not exposed, then a request path (see above) may
> well return different content on subsequent calls, so
> expiration-based caching isn't ideal;

You can use the resulting internal sha1 as the "etag" header which
would cache at the object level rather than at the URL level.

> 2. aren't the cache-control headers for the caches downstream?
> Wouldn't this mean that if 1,000 clients requested a page, the
> reStructuredText processor would have to do the same work 1,000
> times? I'd love to cache the result and serve that while the
> source file's pre-processing mtime hasn't changed.

yes-ish. If you have a caching proxy such as Varnish in front of your
Django server, it can cache the pages coming out and then serve them
to all requesting clients. I haven't dug into how that interacts
with "etag" vs. other cache-control headers, but that's where I'd
start researching. Or just set the other cache-control headers.

-tkc








--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/20141124101138.1a76647e%40bigbox.christie.dr.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment