Oh, I think I see.

You ran bin/storage upgrade?

Chrome is free to send more "If-Modified-Since" headers when you press reload than when you navigate. I have no idea what its exact behaviors are.

I'm using the reload button next to the URL field indeed. I'm not sure this trashes the cache because if that was the case, there would be no 304s, right?

I can't reproduce that unless I actually use the "reload" command to reload the page, which looks like it makes Chrome dump caches on my system.

Thanks @epriestley, much looking forward to have this deployed to Phacility.

Those changes are live on this server now, let us know if you run into issues.

D15642 has additional details, but the new header/cache behavior is:

If someone wants to dig the original change out of the log and send me a revert, I'll upstream it. I think this behavior (30, 29, 28) is probably better in some sense, but the other behavior (1, 2, 3) is very likely better in terms of how many upstream bug reports it generates, and I have no qualms about shipping a worse product that I don't have to support as much.

On this:

D15641 has the technical details, but here's the behavior I've implemented:

If the unique url hash changed whenever the visibility policy changed, that would be fine.

Let me explain the WMF use case a little more. We have lots of users create public tasks, often with pictures attached, which should be private (security/privacy issues, legal issues, etc). We push notifications of new tasks to our public irc channels, and a lot of our users subscribe to huge numbers of projects. So once the task is created, the content is widely dispersed. And we need the ability to make that as private as possible.

Alright, a v0 of this is live here now -- "Move on Workboard" in the "Actions" menu above the comment box. This is a rough cut and we may not keep it in this form, but the infrastructure it needs is built now, at least.

ignore this - test

I'm on my laptop using tethering on T-Mobile right now and I just noticed the user profile photos in the workboards are not being cached. Whenever I reload the page (Chrome 49.0.2623.110 on OS X 10.11.4), these photos reload from scratch. Here are the headers as reported by the Chrome inspector:

This no longer needs to wait for T5873, since enough of that has been sorted out in EditEngine and related work that it can move forward.

I think this is in good shape now, T9606 can track itself.

I think this is in good shape -- Herald is probably a ways out, and the only other chunk here is EditEngine which has a separate task (T9275).

/project/board/2/ always leads to the board and is the canonical URL.

In T10731#168665, @epriestley wrote:

The use of sh as it is written in the documentation is important.

This is what you are intended to write:

$ sh -c 'echo "$0"' xxx
xxx

This is what it looks like you're writing:

$ echo $0 xxx
-bash xxx

At least today, I don't think we can reasonably guess when a table is really a collection of side-by-side comparison images to do anything special with it. I think allowing block-level elements to change behavior based on content would require a total restructuring of how Remarkup parses, and make adding new rules far more complex (see also T10354).

I'm just going to merge this into T10337, which discusses providing modern endpoints. repository.create is a broken mess and we tend to replace it rather than fixing it (it can't reasonably be fixed without breaking the API, anyway, so we'd end up with a new endpoint in effect, regardless). The new diffusion.edit will fix this and the many other problems with repository.create.

The infrastructure changes should now be complete, and we're clear to start experimenting with the UI. Progress so far:

(This is paused since we're waiting on feedback -- if you give it a shot, let us know how things go.)

D15636 is marked as fixing this. Specifically: