Automatic support for OPTIONS and HEAD requests

[hipsterjazzbo]

I'd like to be able to respond to the OPTIONS and HEAD verbs. This could probably be handled automatically, since this package already knows all the details needed to respond to those requests.

An OPTIONS request to a given endpoint should respond with something like this:

HTTP/1.1 200 OK
Host: localhost:8000
Connection: close
Allow: GET,HEAD,POST

Where Allow: lists the other HTTP verbs that are valid for that endpoint.

And a HEAD request should be the same as a GET request, but should return just the headers, without the response body.

I had a go at doing it myself but I'm fairly new to Laravel and I don't think I have the understanding of the internals of the framework to do it well.

[boris-glumpler]

At least for OPTIONS, this should happen already automatically:
laravel/framework#4078

[hipsterjazzbo]

Huh. I tried it, didn't work. Maybe dingo/api interferes with it?

[jasonlewis]

I'll investigate in the coming days. Again I'd say it might have something
to do with the routes being registered as separate collections to Laravel's
regular routes.
On 17 May 2014 17:03, "Caleb Fidecaro" notifications@github.com wrote:

Huh. I tried it, didn't work. Maybe dingo/api interferes with it?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/52#issuecomment-43400265
.

[junxy]

+1
The same problem?

Hi,

I refer to the wiki: https://github.com/dingo/api/wiki/Creating-Endpoints use Route::resource write a demo: https://github.com/junxy/dingo-api-demo

Then test encountered this problem

But it seems other than GET POST method is not supported?

NotFoundHttpException

Symfony\Component\HttpKernel\Exception\NotFoundHttpException:

.../dingo_api_demo/vendor/laravel/framework/src/Illuminate/Routing/RouteCollection.php:140
.../dingo_api_demo/vendor/laravel/framework/src/Illuminate/Routing/Router.php:1021
.../dingo_api_demo/vendor/dingo/api/src/Routing/Router.php:283
.../dingo_api_demo/vendor/laravel/framework/src/Illuminate/Routing/Router.php:989
.../dingo_api_demo/vendor/laravel/framework/src/Illuminate/Routing/Router.php:968
.../dingo_api_demo/vendor/dingo/api/src/Routing/Router.php:148
.../dingo_api_demo/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:738
.../dingo_api_demo/vendor/laravel/framework/src/Illuminate/Foundation/Application.php:708
.../dingo_api_demo/vendor/symfony/http-kernel/Symfony/Component/HttpKernel/Client.php:81
.../dingo_api_demo/vendor/symfony/browser-kit/Symfony/Component/BrowserKit/Client.php:334
.../dingo_api_demo/app/tests/ExampleTest.php:32

Thanks!

[hipsterjazzbo]

After further investigation, OPTIONS does actually work, although it includes a response body of {"message":""}, which it shouldn't.

HEAD still seems not to work, although I couldn't get it to go in a normal route either, so it either may not be implemented in Laravel, or it's just PEBKAC.

[philsturgeon]

This is working for me in 4.1.

I am using 4.1 and these are not resource routes, they are hard-coded routes.

[hipsterjazzbo]

@philsturgeon Have a look at my previous comment. OPTIONS works but returns stuff in the body which it shouldn't.

In Postman, if I do a HEAD request I get headers, but I get "Malformed JSON" in the body, which I guess could be just Postman being a bit dopey?

[philsturgeon]

I noticed the latter, but not the former. 

[jasonlewis]

I believe the problem with content appearing in the response body should have been rectified in fbda8b1. Automatic OPTIONS requests should work, I don't believe HEAD is a part of Laravel.

[johnnygreen]

I just recently updated an old L4.1 api to L4.2 and ran into an issue. Laravel is now auto responding to OPTIONS request when one is not defined (712963f). I used to be able to catch the NotFoundHttpException, check for OPTIONS and respond with it like so:

$request = \Route::getCurrentRequest();
$request->setMethod($request->header('Access-Control-Request-Method'));
$routes  = \Route::getRoutes();
$route   = $routes->match($request);

return \Response::make('', 200, [
  'Access-Control-Allow-Origin'  => '*',
  'Access-Control-Allow-Methods' => implode(',', $route->methods()),
  'Access-Control-Allow-Headers' => 'accept, authorization, content-type'
]);

Curious... I know the spec still states "Allow" as the header (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html), but I can only get "Access-Control-Allow-Methods" to work in FF, Chrome, Safari.... (https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS)

So having Laravel respond with "Allow" automatically and creating a route is making it hard to do things in an efficient manner without having to manually define an OPTIONS route for all my resource routes.

Any thoughts? Could we support both headers? Am I doing it all wrong?

[jasonlewis]

Tried using an after filter to set the CORs headers?

On Sat, 14 Feb 2015 11:54 Johnny Green notifications@github.com wrote:

I just recently updated an old L4.1 api to L4.2 and ran into an issue.
Laravel is now auto responding to OPTIONS request when one is not defined.
I used to be able to catch the NotFoundHttpException, check for OPTIONS and
respond with it like so:

$request = \Route::getCurrentRequest();$request->setMethod($request->header('Access-Control-Request-Method'));$routes = \Route::getRoutes();$route = $routes->match($request);return \Response::make('', 200, [ 'Access-Control-Allow-Origin' => '*', 'Access-Control-Allow-Methods' => implode(',', $route->methods()), 'Access-Control-Allow-Headers' => 'accept, authorization, content-type']);

Curious... I know the spec still states "Allow" as the header (
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html), but I can only
get "Access-Control-Allow-Methods" to work in FF, Chrome, Safari.... (
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS)

So having Laravel respond with "Allow" automatically and creating a route
is making it hard to do things in an efficient manner without having to
manually define an OPTIONS route for all my resource routes.

Any thoughts? Could we support both headers? Am I doing it all wrong?

—
Reply to this email directly or view it on GitHub
#52 (comment).

[johnnygreen]

Got it! Thank you. This seems to have done the trick:

// routes.php
<?php

Route::after('v1\Filter\CorsFilter');

// library/v1/Filter/CorsFilter.php
<?php namespace v1\Filter;

use Symfony\Component\HttpKernel\Exception\NotFoundHttpException;

class CorsFilter {

  public function filter($request, $response)
  {
    $response->headers->set('Access-Control-Allow-Origin', '*');
    $response->headers->set('Access-Control-Allow-Headers', 'accept, authorization, content-type');

    if ($request->isMethod('OPTIONS'))
    {
      $request->setMethod($request->header('Access-Control-Request-Method'));
      $routes = \Route::getRoutes();

      try
      {
        $route = $routes->match($request);
      }
      catch(NotFoundHttpException $exception)
      {
        $route = null;
      }

      if ( ! is_null($route))
      {
        $response->headers->set('Access-Control-Allow-Methods', implode(',', $route->methods()));
      }
    }
  }

}