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

Destination with content-type : application/x-www-form-urlencoded #12

Open
Drastef31 opened this issue Mar 3, 2022 · 3 comments
Open
Labels
enhancement New feature or request question Further information is requested

Comments

@Drastef31
Copy link

Hello
Unless I'm wrong (or I do something wrong), It seems that Octohook cannot forward POST HTTP request with content-type set to : application/x-www-form-urlencoded.
I have an incoming webhook with content-type set to application/x-www-form-urlencoded, but the destination seems to be always addressed with application/json, whatever the source headers.
I have the same result if I connect directly the incoming webhook headers with the headers of the destination, or if I edit the headers manually.
When I check the "preview" of the destination, in the right part of the screen, it seems that the field content-type is set correctly to application/x-www-form-urlencoded, but at reception side, the HTTP request actually forwarded is always in application/json format.
Is it a bug ? or do I do something wrong ?
thank you

@slashequip
Copy link
Contributor

Hey @Drastef31 👋 , thanks for reaching out.

This is likely overridden by our outgoing http workers - because that is how we expect to send data - via JSON.

The preview isn't actually sending anything it is just generating that data.

I'd have to look a little deeper into the consequences of allowing user to override the content-type header - this will likely impact further things too like how we actually send the data.

Out of curiosity, can you give me an indication of where (or what) you are sending that explicitly requires that content type?

Thanks! 🙂

@Drastef31
Copy link
Author

Drastef31 commented Mar 6, 2022 via email

@slashequip
Copy link
Contributor

Ok makes sense, and thanks for the insight, I'll make a note to take a look - as mentioned there are likely a lot of downstream issues from just 'allowing that header' so I don't think it will be a quick fix but I'll provide any updates I have here.

@slashequip slashequip added enhancement New feature or request question Further information is requested labels Mar 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants