PUT request generates SPDY protocol errors only in Chrome or Opera?

Question

I have an Angular 1.5 app that uses the Angular $resource provider to handle all calls to the API backend. I recently added a feature that has a drag and drop interface, and once an item is dropped into a particular bucket I perform a PUT request with all relevant data to the public API method to save said data.

I developed it a few months back, and even uncovered an odd bug in the Mac-only version of Chrome in one particular version (we're already 2 or 3 versions past that), but otherwise it worked perfectly.

I just recently released it after doing some more testing on my own, only to realize that Chrome and Opera browsers both error out on the PUT call, the API never receives the request. The only piece of information I get is this description in the Chrome console:

PUT https://www.phpdraft.com/api/draft/59/pick/5026/depth_chart/37 net::ERR_SPDY_PROTOCOL_ERROR

To see this for yourself, here's the URL where that call or similar ones can be made: PHPDraft

I suspect that the fact that my server is using HTTPS may be the issue at hand here, but the Google searches I've done on ERR_SPDY_PROTOCOL_ERROR so far are cryptic at best and don't sound as if they apply to my situation.

Here's how I'm using $resource within my Angular app to make this PUT call (and all other calls similarly):

angular.module('app').factory('api', function($resource, ENV) {
  return {
    DepthChartPosition: $resource(ENV.apiEndpoint + "commish/draft/:id/depthchartposition/:position_id", {
      draft_id: '@draft_id',
      position_id: '@position_id',
      draft_sport: '@draft_sport',
      manager_id: '@manager_id',
      pick_id: '@pick_id'
    }, {
      'update': {
        method: 'PUT',
        url: ENV.apiEndpoint + "draft/:draft_id/pick/:pick_id/depth_chart/:position_id"
      }
    })
  };
});

And here's what the request itself that is generated by the above code looks like:

General
Request URL:  https://www.phpdraft.com/api/draft/59/pick/5026/depth_chart/37

Request Headers
Accept:application/json, text/plain, */\*
Content-Type:  application/json;charset=UTF-8
Origin:  https://www.phpdraft.com
Referer:  https://www.phpdraft.com/draft/59/depth_chart
User-Agent:  Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.116 Safari/537.36

Request Payload
{draft_id: "59", position_id: "37", pick_id: "5026"}

The response window for this request is empty, and devtools shows the request as "stalled". Any ideas what's going on here?

Replicated error on Chrome in Linux. First google search results suggested going to chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active and flushing sockets. Tried that with no change in results. Note, I did have this error prior to the SPDY error `Failed to parse SourceMap: https://www.phpdraft.com/js/affix.min.js.map` — Zoot, Aug 17 '16 at 01:40
It's also interesting that you get the affix map error as well. I explicitly do not build the app to use sourcemaps, so it's curious that that one sticks around (I see it too). I'll enter a separate bug. — Mattygabe, Aug 17 '16 at 12:16

score 2 · Accepted Answer · answered Aug 17 '16 at 01:58

2

As of May 15th of this year, Chrome no longer supports SPDY and is no longer included in the current version.

... starting on May 15th — the anniversary of the HTTP/2 RFC — Chrome will no longer support SPDY.

...SPDY and NPN support will be removed with the release of Chrome 51.

answered Aug 17 '16 at 01:58

Rob

14,746
28
47
65

1

I never explicitly told my application or server to use the SPDY protocol (in fact, since I got to see Robert Boedigheimer's talk on HTTP/2 I'm pretty familiar with what it is and what purpose it has served), so why would both Chrome and Opera be giving this error? My Chrome's settings have SPDY explicitly off (but HTTP/2 is on). – Mattygabe Aug 17 '16 at 12:15
@Mattygabe SPDY needs to be set on the server side, too, as does HTTP/2. Opera might behave the same as Chrome because it uses, Blink, the same engine as Chrome. – Rob Aug 17 '16 at 12:33
I checked with my host (Accuwebhosting) and they said they can't drop SPDY in favor of HTTP/2 because it's shared hosting and it may affect other customers. I say that's pretty poppycock as SPDY has been just an experimental testing ground for the HTTP/2 working group and wasn't intended for production use anywhere. Time to find a new host! – Mattygabe Aug 18 '16 at 13:44

PUT request generates SPDY protocol errors only in Chrome or Opera?

1 Answers1