Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content-type not set when function returning a domain representing media type is requested with Accept "*/*" header #3391

Open
mkleczek opened this issue Apr 9, 2024 · 4 comments
Labels

Comments

@mkleczek
Copy link

mkleczek commented Apr 9, 2024

Environment

  • PostgreSQL version: 16
  • PostgREST version: 12.0.2
  • Operating system: Windows

Description of issue

I have the following function:

CREATE DOMAIN "text/javascript" AS text;
CREATE OR REPLACE FUNCTION "module.js"() RETURNS "text/javascript"...

When requested by a browser from:

<script type="module" src="/rpc/module.js"></script>

returned response Content-Type is application/json

It seems the browser is setting Accept header to */* and PostgREST does not set proper content type in this case.
As a workaround it is necessary to explicitly set content type in the function using current_setting.

@steve-chavez
Copy link
Member

This needs the any handler as mentioned on #3387 (comment)

@wolfgangwalther
Copy link
Member

Sorry, but that's still a bug. The function definition clearly tells us that this function is only ever going to return text/javascript, so we should never choose application/json when the header is */*.

@steve-chavez
Copy link
Member

I agree that this is the ideal behavior and I gave it a shot on steve-chavez@760f5ac. Adding support for this is simple enough but it's hard to retrofit it with the current table media handlers done with aggregates, many tests break.

Likely we will need to adjust aggregates behavior and cause breaking changes, so I will leave this for a next major version.

@wolfgangwalther
Copy link
Member

I'm probably missing something, but shouldn't this just be solved on the haskell part of the code? We should have all information available already, no? I don't understand why we'd need to query more stuff from the SQL side for this. I would have expected we'd just need to adjust the logic where the actual negotiation happens. What am I missing?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants