PATCH requests being issued as patch (lowercase), invalid against HTTP/1.1

[robacarp]

I'm not entirely sure where the blame lies, but there is something weird going on with my swagger-ui installation. Our internal usage of swagger-ui shows that Rack is receiving http requests such as this:

patch /api/v1/spaces/2 HTTP/1.1
Host: localhost:3000
Connection: keep-alive
Content-Length: 13
Accept: application/json
Origin: http://localhost:3000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.95 Safari/537.36
Content-Type: application/x-www-form-urlencoded
DNT: 1
Referer: http://localhost:3000/docs
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8

deleted=false

Our server complains on receipt of that http request: Invalid request: Invalid HTTP format, parsing fails.

POST and GET requests go through just fine, and are rendered with uppercase method names:
GET /api/v1/spaces/1 HTTP/1.1 POST /api/v1/spaces HTTP/1.1

Upon extracting the request and modifying the request packet to read PATCH instead of patch, and replaying the request, it succeeds decoding and the server accepts it.

During my digging, I came across the http spec at ITEF, which lists only uppercase method names (however maybe the spec is out of date, since this copy doesn't list PATCH at all).

I started digging through the source, and I'm admittedly not a coffeejs dev, so I didn't get too far, but I have a hunch that patch wasn't considered quite as much as the other methods might have been. I suspect that many http servers are a little less pedantic about the letter case of the request method, so this might go un noticed for a while.

[fehguy]

can you please provide three pieces of info:

1. the swagger spec version that you're using
2. the version of swagger-ui (from the head of swagger-ui.js)
3. the versions of swagger.js and swagger-client.js?

[robacarp]

@fehguy sure. Thanks for the reply.

1. We're developing against this swagger-2 spec. There are some holes in the docs, but our API is relatively simple, so we pulled through.

2. Swagger-ui.js: version 2.1.0-alpha.7

3. swagger.js is 2.0.41 and swagger-client.js is 2.1.0-alpha.2

I doubt it will matter, but here is an except from the json object we're generating for a patch endpoint:

{
    "info": {...},
    "paths": {
        "/v1/content/canvases": {},
        "/v1/content/canvases/{id}": {
            "get": {...},
            "patch": {
                "description": "Update a canvas's object",
                "method": "patch",
                "parameters": [
                    {
                        "description": null,
                        "in": "path",
                        "name": "id",
                        "required": null,
                        "type": "string"
                    },
                    {...},
                    {...},
                    {...},
                    {...},
                    {...},
                    {...},
                    {...},
                ]
            }
        }
    },
    "swagger": "2.0"
}

[webron]

@robacarp - can you try pulling the latest master? It contains newer versions of swagger.js and swagger-client.js. I tested it earlier and it seems to work fine (tested against http://petstore.swagger.wordnik.com/v2/swagger.json).

[robacarp]

@webron sure, and thanks for looking. I also saw the working petstore example and wasn't able to sort out what the difference is. I've updated these files to the latest versions:

• lib/swagger-client.js
• lib/swagger-oauth.js
• lib/swagger.js
• swagger-ui.js
• swagger-ui.min.js

Replacing those files resolved the diff, with the exception of index.html, which is slightly more complicated because we've customized it for our auth needs. I swapped out our index.html for the vanilla version, changed the api lookup url, and I'm still seeing the failure.

From the dist-version of index.html, when I try to test a PATCH route, I get this in console:

I've included a seemingly equivalent patch request from the correctly working petstore example as a reference.

Thanks again for looking!

[webron]

Okay, I think the problem is that I tested with 1.2, and it may be specific for 2.0.

Upon making changes to the 2.0 petstore and add the patch call that exists in 1.2, I get an error on the OPTIONS call, and it looks like there's indeed a problem.

The relevant request header sent by the OPTIONS request is:

Access-Control-Request-Method:patch

and it should definitely be PATCH.

The server replies with:

Access-Control-Allow-Methods:GET, POST, DELETE, PUT, PATCH, OPTIONS

[fehguy]

this has been addressed in the develop_2.0 branch