Clarify whether path matches cross-origin or just same origin

[jeffposnick]

There are some places in the docs that state that path will only match same-origin requests, but @wibblymat didn't think that was the case after looking at the sw-toolbox source. I need to double-check and most likely update the docs to reflect that cross-origin requests are matched as well.

[ebidel]

FWIW, I can't get anything XD to cache. For example:

<platinum-sw-fetch origin="https://content\\.googleapis\\.com"
  path="/plus/v1/people/me"></platinum-sw-fetch>

[jeffposnick]

I've experimented a bit more and think I have a better idea as to what's going on under the hood in sw-toolbox and how it relates to the options that are passed through via the Polymer wrapper. @wibblymat, it would be great if you could confirm my conclusions.

When using <platinum-sw-cache default-cache-strategy="...">, that handler will be applied to all requests, both same or cross-origin.

When using <platinum-sw-fetch> to define a custom handler for a certain subset of requests, there are two possibilities.

• If you set path and don't set origin, then the handler will be applied only to same-origin requests that match path.
• If you set path and origin, then the handler will be applied to requests that match both, which is how you can apply a specific handler for cross-origin requests.

Regarding what @ebidel is seeing, first off, the docs are incorrect about the need to double-escape (bug), so you'd actually want origin="https://content\.googleapis\.com". Second, you're not defining a handler in your <platinum-sw-fetch>, so it would effectively be a no-op anyway. (Bug tracking how to communicate that to developers.)

If your goal is to use something other than the default caching strategy for https://content.googleapis.com/plus/v1/people/me requests, then you should be able to do that with

<platinum-sw-fetch origin="https://content\.googleapis\.com"
                   path="/plus/v1/people/me"
                   handler="nameOfHandler"></platinum-sw-fetch>

nameOfHandler could be something like networkOnly if you're trying to avoid serving those requests from the cache.

I'll follow up with a PR to address the issues raised in the bugs, and some additional test cases to catch them.

[wibblymat]

@jeffposnick you beat me to it :)

Yes, that is correct. Routes are all same-origin unless specified otherwise, except the default route. It's the default route case that I brought up before our I/O talk.