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