swagger2-koa
swagger2-koa copied to clipboard
carlansley
Do not return 405 on undefined OPTIONS request
Coverage remained the same at 100.0% when pulling 888c93f9268a43a991baa509cdf809412dd0b551 on shaxbee:master into 412026ced32290c981fa281d0274a6382f133a8a on carlansley:master.
Coverage remained the same at 100.0% when pulling b1f72ac5496456c83b54a3559f91ab65598ebfd6 on shaxbee:master into 412026ced32290c981fa281d0274a6382f133a8a on carlansley:master.
Hi thanks for the PR. Can you talk a little about your use case, assume it's CORS related? I'm not entirely clear on why we should treat the OPTION verb differently from the others, would be good to have some context.
Hello Carl,
OPTIONS is usually provided by middleware in wide range of web frameworks and is usually unrelated to the business logic in REST calls. It's used by the browser to preflight cross origin request by checking if certain origin, headers, etc are allowed.
Adding it to swagger.yaml adds unnecessary boilerplate as it's related to HTTP protocol operations rather than business logic.
Regards, Zibi
On Fri, Dec 16, 2016, 1:24 AM Carl Ansley [email protected] wrote:
Hi thanks for the PR. Can you talk a little about your use case, assume it's CORS related? I'm not entirely clear on why we should treat the OPTION verb differently from the others, would be good to have some context.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/carlansley/swagger2-koa/pull/6#issuecomment-267387877, or mute the thread https://github.com/notifications/unsubscribe-auth/AE_mfX6VbXl1lFi6-qZ-ptIo24SMoCMfks5rIXfYgaJpZM4LNzoG .
I suppose it comes down to the "unnecessary boilerplate" thing. I agree it's annoying, but if you're also using your swagger with something like API Gateway you can't get around it:
http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html
We use the same swagger files with both so any difference in behavior is not ideal for us. Maybe an option flag that turns it on/off (default off) makes everyone happy?
Hiding it behind flag sounds very reasonable, I'll update PR to reflect that. What do you wish to do about HEAD request?
On Sat, Dec 17, 2016, 1:04 AM Carl Ansley [email protected] wrote:
I suppose it comes down to the "unnecessary boilerplate" thing. I agree it's annoying, but if you're also using your swagger with something like API Gateway you can't get around it:
http://docs.aws.amazon.com/apigateway/latest/developerguide/how-to-cors.html
We use the same swagger files with both so any difference in behavior is not ideal for us. Maybe an option flag that turns it on/off (default off) makes everyone happy?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/carlansley/swagger2-koa/pull/6#issuecomment-267642295, or mute the thread https://github.com/notifications/unsubscribe-auth/AE_mfdYUTaxK2cVhlRyPEV3LHx8fbp0Xks5rIsSKgaJpZM4LNzoG .
What would you propose for default functionality for HEAD? Do you see an issue with the current behavior?
HEAD is also usually handled by server/middleware and used to communicate resource headers without sending the body for things like caching. Maybe an array of request types to skip would be more beneficial?
On Sat, Dec 17, 2016, 2:16 AM Carl Ansley [email protected] wrote:
What would you propose for default functionality for HEAD? Do you see an issue with the current behavior?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/carlansley/swagger2-koa/pull/6#issuecomment-267659970, or mute the thread https://github.com/notifications/unsubscribe-auth/AE_mfZCHjVbgvopqId4CkK2Slf4TMg-fks5rItVggaJpZM4LNzoG .
We use HEAD quite a bit in our REST APIs, it has specific semantics that are useful, so don't agree it's simply a middleware thing. But I'm fine with your solution of an array of HTTP verbs to ignore if undefined in the swagger.