search

octohk / feedback

A place to give feedback and raise issues about octohook.com
2 stars 0 forks source link

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

Open Drastef31 opened 2 years ago

Drastef31 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

Thank you for your feedback.

In my application, the HTTP request are used to remotely control my home automation (control heat, doors, etc..). My system is called Jeedom and expect commands in url-encoded format. It accepts also json, but things are not as simple as with url-encoded format in json, that’s why I looked for a solution that support that format.

slashequip commented 2 years ago

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.