Hello Jim, Sorry about this. I've dug around a bit and I believe the root cause is due to platinum-sw depending on sw-toolbox ^2.0.4 <https://github.com/PolymerElements/platinum-sw/blob/master/bower.json#L27>, while the fix <https://github.com/GoogleChrome/sw-toolbox/pull/39> to bypass the default route for non-GET requests didn't make it into sw-toolbox until version 3.0.x.
Can you try temporarily modifying your bower.json to pull in version "polymerelements/platinum-sw#bump-sw-toolbox" in your platinum-sw dependency? We'll be cutting a new official release for platinum-sw that includes the updated dependency, but it would be great to hear confirmation from you that this resolves it for you. Cheers, -j On Fri, Feb 5, 2016 at 1:07 AM, Jim Trainor <[email protected]> wrote: > This question now posted on stackoverflow: > > > http://stackoverflow.com/questions/35214589/polymer-polymer-sw-service-worker-transparent-409-put-response > > I’d really love to get the bottom of this. My entire application works > great offline… except for this :( … so I have to disable the service > worker. This is important because offline-ready applications with > fully-baked cache implementations that exist outside the domain of the > service-worker have to deal with 409 error cleanly (as mine does, on all > browsers, with or without service worker support!). The service work in my > case just takes care of caching the site’s static content and that much > works great. It has to stay out of the way of the rest of the application. > > p.s. I upgraded to platinum-sw 2.0.0. Same behaviour. > > > On Mon, Feb 1, 2016 at 7:43 PM, Jim Trainor <[email protected]> > wrote: > >> Handling only GET requests makes sense. But the PUT requests are being >> touched somewhere/somehow it appears. If I disable platium-sw-cache using >> the “disabled” property my own code gets the 409 response as expected. >> When enabled, my code never sees the 409 response. So something appears to >> be amiss. >> >> On Mon, Feb 1, 2016 at 5:18 PM, Jeffrey Posnick <[email protected]> wrote: >> >>> Under the hood, <platinum-sw-fetch> ends up calling toolbox.router.get() >>> <https://github.com/GoogleChrome/sw-toolbox/pull/11>, to register what >>> should be a GET-only handler. I would expect PUT requests to be bypassed as >>> if there were no service worker involvement. >>> >>> I'll look into it more and see if I can reproduce. I'm also CC:ing Mat, >>> who authored sw-toolbox, the underlying library. >>> >>> Cheers, >>> -j >>> >>> On Sun, Jan 31, 2016 at 4:29 PM, Rob Dodson <[email protected]> >>> wrote: >>> >>>> +Jeff, who may know more >>>> >>>> On Sun, Jan 31, 2016 at 1:02 PM, Jim Trainor < >>>> [email protected]> wrote: >>>> >>>>> I'm using platinum-sw and I have a platinum-sw-fetch handler >>>>> configured to ignore paths that are in my application's xhr request api. >>>>> I >>>>> have configured a platinum-sw-fetch handler expecting to handle both http >>>>> GET and PUT requests by simply passing them through the client using a >>>>> "fetch" call. >>>>> >>>>> <platinum-sw-register ... > >>>>> <platinum-sw-fetch handler="doNativeFetch" path="/myservice(.*)" >>>>> ></platinum-sw-fetch> >>>>> . >>>>> . >>>>> . >>>>> </platinum-sw-register> >>>>> >>>>> >>>>> var doNativeFetch = function doNativeFetch(request, values, options) { >>>>> console.log('doNativeFetch request', request, values, options); >>>>> return fetch(request); >>>>> }; >>>>> >>>>> >>>>> This works as expected for GET requests. I see GET request to >>>>> "/myservice/..." logged by my custome doNativeFetch handler, the service >>>>> worker doesn't cache these requests as expected. Http PUT requests also >>>>> work (from the clients perspective) but they do *not* appear to be >>>>> directed to my doNativeFetch handler - I never see my "doNativeFetch" log >>>>> message. This causes a problem when my server returns an 409 status to a >>>>> PUT request (in response to a client's attempt to write state data). My >>>>> application code expectes to handle this 409 error when it occurs. But I >>>>> never see the error when I run with the platinum-sw service worker >>>>> enabled. Instead I see the following in Chrome's console: >>>>> >>>>> >>>>> (Here is clients http request) >>>>> XHR finished loading: PUT "https://abc.example.com/myservice/12345";. >>>>> >>>>> (Immediately followed by this, which appears to be the service layer >>>>> intercept, no my doNativeFetch handler). >>>>> PUT https://abc.example.com/myservice/12345 409 (OK) <<< expected, >>>>> good so far! >>>>> The FetchEvent for "https://abc.example.com/myservice/12345"; resulted >>>>> in a network error response: an object that was not a Response was >>>>> passed to respondWith() <<< the 409 is not passed-thru, where do I >>>>> hook into respondWith? >>>>> >>>>> (Immediately followed by this, which is my client layer code getting >>>>> a net::ERR_FAILED rather than the 409 http response - bad!). >>>>> PUT https://abc.example.com/myservice/12345 net::ERR_FAILED <<<< >>>>> problem, client doesn't get the 409 >>>>> >>>>> >>>>> ... after much digging, I am a loss as to how to proceed with this. The >>>>> most basic issue is that my custom platinum-sw-fetch handler is never >>>>> called for the PUT request. How to I configure a platinum-sw-fetch >>>>> handler that will intercept a PUT request and allow me to pass a 409 >>>>> error through to the calling client? Or is that the wrong stategy >>>>> entirely? Perhaps somewhere I provide a FetchEvent.respondWith >>>>> implementation? But where and how? >>>>> >>>>> >>>>> >>>>> Follow Polymer on Google+: plus.google.com/107187849809354688692 >>>>> --- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Polymer" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/polymer-dev/ae19fc55-5732-4343-b29a-4c8281023a84%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/polymer-dev/ae19fc55-5732-4343-b29a-4c8281023a84%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>> >> > Follow Polymer on Google+: plus.google.com/107187849809354688692 > --- > You received this message because you are subscribed to the Google Groups > "Polymer" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/polymer-dev/CACDv4tBs0Q87sPur9GmgsVKqjKNsmtJO%2B%3DSnV3Ed54RLqWJjQg%40mail.gmail.com > <https://groups.google.com/d/msgid/polymer-dev/CACDv4tBs0Q87sPur9GmgsVKqjKNsmtJO%2B%3DSnV3Ed54RLqWJjQg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAFt5L5aMjHUogmm27ZeS1kR1we6fBH%2BCThLHTQJXEMqiGjnnng%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
