Resolve relative paths to a hypothetical root before fetching docs from source control.

Resolve relative paths to a hypothetical root before fetching docs from source control.

BUG=None
TEST=None

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=68744

[kurrik.chromium, 2010-11-18 00:55:01]

One more quick patch to the docs server.  This is also deployed.

[Aaron Boodman, 2010-11-19 01:30:30]

+asargent, who might know more Python than me.

What is the intention of this change? Is it to handle things like "../", or to
do some other kind of normalization?

[asargent_no_longer_on_chrome, 2010-11-19 18:02:57]

This looks ok to me. Perhaps Carl could also take a look to see if there's
anything we've missed? I know he has more python and app engine experience than
I do.

[Carl Nygaard, 2010-11-19 20:14:22]

LGTM

Seems like an important change.  Without this change, it looks like it would
have been possible to fetch most anything from the chromium source and serve it
up, which would have had all kinds of issues.

I looked through the rest of the code as well.  I don't see any obvious pressing
issues.

It is a little strange that we forward all the headers.  I'd probably rather see
a set of white-listed headers, e.g. mime type (is there any other header that is
useful?)

For example, looking at the headers we reply with, it's a bit questionable that
we serve:

cache-control: max-age=600

If we had a lot of traffic, then we would likely need to worry about proxies
caching content from request to request (thus bypassing our browser version
logic).  If it were me, I'd wipe all the caching headers and just always respond
with

Cache-Control: no-cache

In any case, it's working fine for now, so not a big deal.

[asargent_no_longer_on_chrome, 2010-11-19 20:22:32]

If we wanted to get fancy, we'd store the expected expiration time in
memcache, and serve up an Expires header with that time (maybe somehow
staggered to avoid thundering herd, although I doubt our traffic is so much
that we'd really have to worry about that).

On Fri, Nov 19, 2010 at 12:14 PM, <cnygaard@chromium.org> wrote:

> LGTM
>
> Seems like an important change.  Without this change, it looks like it
> would
> have been possible to fetch most anything from the chromium source and
> serve it
> up, which would have had all kinds of issues.
>
> I looked through the rest of the code as well.  I don't see any obvious
> pressing
> issues.
>
> It is a little strange that we forward all the headers.  I'd probably
> rather see
> a set of white-listed headers, e.g. mime type (is there any other header
> that is
> useful?)
>
> For example, looking at the headers we reply with, it's a bit questionable
> that
> we serve:
>
> cache-control: max-age=600
>
> If we had a lot of traffic, then we would likely need to worry about
> proxies
> caching content from request to request (thus bypassing our browser version
> logic).  If it were me, I'd wipe all the caching headers and just always
> respond
> with
>
> Cache-Control: no-cache
>
> In any case, it's working fine for now, so not a big deal.
>
>
> http://codereview.chromium.org/5188003/
>

[Aaron Boodman, 2010-12-07 00:20:18]

Status? can this be closed?