[
https://issues.apache.org/jira/browse/SHINDIG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Brown updated SHINDIG-57:
-------------------------------
Attachment: headers.patch.txt
Updated patch to reflect recent discussion.
I will apply this version of the patch around 7PM PST if nobody objects. If
you're not using BasicRemoteContentFetcher or if you were depending on the
current broken behavior this means you :)
As an aside -- I was considering just passing the headers as normal HTTP
headers, and using -X-shindig-authz and the like for our own control headers.
This way the post body wouldn't have to be mangled so badly. Can anyone think
of a good reason not to do this?
> gadgets.io.makeRequest does not pass a content-type on POST requests
> --------------------------------------------------------------------
>
> Key: SHINDIG-57
> URL: https://issues.apache.org/jira/browse/SHINDIG-57
> Project: Shindig
> Issue Type: Improvement
> Components: Gadgets Server - Java
> Reporter: Arne Roomann-Kurrik
> Assignee: John Hjelmstad
> Attachments: add-content-type.patch.txt, headers.patch.txt,
> headers.patch.txt
>
>
> When using gadgets.io.makeRequest to POST data to a remote server, the
> Content-Type header is not set.
> PHP expects the Content-Type header to be set to
> "application/x-www-form-urlencoded" in order to populate its $_POST variable
> with the passed data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
