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. For more options, visit https://groups.google.com/d/optout.
