Meu aplicativo usa um bookmarklet e preciso permitir o CORS paraMyRouteR então meu código de bookmarklet pode usar esta rota para solicitações de AJAX.

No meu primeiro rascunho de config / routes eu deiMyRouteR suporte para apenas um método de solicitação, PUT. Mas acabou (duh) que eu precisaria suportar também o método OPTIONS, que navegadores usam para solicitações de preflight do CORS.

Acabei com o seguinte em config / routes:

/myroute MyRouteR PUT OPTIONS

Eu meio que esperava que houvesse alguma maquinaria relevante no Template Haskell que processe config / routes para que a adição de OPTIONS à lista de métodos dessa rota resultasse automaticamente no suporte a CORS, mas sem dados. Não é o fim do mundo, mas faria sentido e seria elegante assim.

Para fazer o CORS funcionar, eu dei à rota um manipulador OPTIONS:

optionsMyRouteR :: Handler RepPlain
optionsMyRouteR = do
    addHeader "Access-Control-Allow-Origin" "*"
    addHeader "Access-Control-Allow-Methods" "PUT, OPTIONS"
    return $ RepPlain $ toContent ("" :: Text)

putMyRouteR :: Handler RepJson
putMyRouteR = do
    addHeader "Access-Control-Allow-Origin" "*"
    -- more stuff ...

Isso funciona, mas parece um pouco não-simódico porque é tão clichê. Então, duas perguntas:

Temos um adjetivo melhor que o Yesodico?Existe outra maneira melhor de permitir que uma rota ofereça suporte a solicitações de origem cruzada?