platium-sw, fetch handler for put requests, dropping 409 status

[Jim Trainor]

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?

[Rob Dodson]

+Jeff, who may know more

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 polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/ae19fc55-5732-4343-b29a-4c8281023a84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jeffrey Posnick]

Under the hood, <platinum-sw-fetch> ends up calling toolbox.router.get(),  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

[Jim Trainor]

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.

[Jim Trainor]

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.

[Jeffrey Posnick]

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, while the fix 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

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CACDv4tBs0Q87sPur9GmgsVKqjKNsmtJO%2B%3DSnV3Ed54RLqWJjQg%40mail.gmail.com.

[Jim Trainor]

Updating to "polymerelements/platinum-sw#bump-sw-toolbox" did fix the problem.  I replied confirming that back early in February but don't see my reply here. I replied via email... maybe it got lost somehow or did not go where I intended.  Anyway. That update worked back then.  I guess that was temporary tag?  It doesn't work now.  I see that the github head for platinum-sw references sw-toolbox 3.1.1.  Any idea when the platinum-sw 1.2.4 releaese will be created so that we can pick up the sw-toolbox dependency update?

many thanks

[Jeffrey Posnick]

Hello Jim,

 Sorry about the delay. https://github.com/PolymerElements/platinum-sw/releases/tag/v1.3.0 has been tagged.

Cheers,

-j

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 polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/229f334b-2b76-4559-8f17-0737fe1077c4%40googlegroups.com.