None standard http headers are not supported? about cro-webapp HOT 9 CLOSED

The problem is that the response already has a text/html content type and you're appending another, but specifying multiple content types isn't valid. I have no experience with Cro and don't know if this is the correct solution, but you could do .remove-header('Content-type') before appending your own.

You might want to leave this issue open for someone more knowledgeable to chime in, there may be a more elegant way to specify it earlier in the pipeline when the response is initially constructed.

from cro-webapp.

I just had a look at your project. You're calling template, which sets text/html by default according to the docs. Adding content-type => 'image/svg+xml' should do the trick. And you can skip all the manual fiddling with headers. Should look something like this:

template 'templates/badge.crotmp', {
      project => $project, 
      state => $state
    },
    content-type => 'image/svg+xml';

See also https://cro.services/docs/reference/cro-webapp-template and

from cro-webapp.

.remove-header('Content-type') did not help, get the same error. so I ended up using http permanent redirects to static images

from cro-webapp.

Odd, it worked for me in a small test directly using parts of Cro::HTTP. There must be something more going on elsewhere in the execution. Glad you have a workaround for now, though.

from cro-webapp.

@raydiak thanks a lot. Honestly I already rewritten the code to use permanent redirect, but I'll consider this solution for the future in case I decide to revert changes and go with template way ... But thanks!

PS cro supporters, should we close this issue or leave it, so someone would update the respected cro templates documentation?

from cro-webapp.

I figured, I just wanted to see it though. Serving static resources through a script is usually better avoided anyway. At least now you know how it works for the future. And you're welcome, of course!

As far as the docs go, they're pretty clear and explicit about this if you look at the one I linked. Is there another document somewhere which gave you the impression that this should work?

The only potential issues I see here are whether template should be adding a content type if one is already set, and if multiple content types should be able to be set at all. At the least, perhaps the error could have something like "Is more than one content type specified?" appended after the parse failure message.

from cro-webapp.

template forcefully set a certain content type, without option to override the one via . append-header. This seems like a bug for me.

from cro-webapp.

The template function (like content, which it in turn calls) takes a content-type option. I just checked if this is documented, and it indeed is. I have, however, tweaked content to make sure that it overrides any existing content-type header.

from cro-webapp.

cool, thanks

from cro-webapp.