You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Arne Roomann-Kurrik (JIRA)" <ji...@apache.org> on 2008/02/09 20:04:07 UTC

[jira] Created: (SHINDIG-57) gadgets.io.makeRequest does not pass a content-type on POST requests

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


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.


[jira] Updated: (SHINDIG-57) gadgets.io.makeRequest does not pass a content-type on POST requests

Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SHINDIG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Brown updated SHINDIG-57:
-------------------------------

    Attachment:     (was: headers.patch.txt)

> 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
>
>
> 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.


[jira] Updated: (SHINDIG-57) gadgets.io.makeRequest does not pass a content-type on POST requests

Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
     [ 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

Here's a much more thorough patch that should address this issue as well as several other open gadgets.io-related bugs. I will apply this monday after getting feedback.

> 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
>
>
> 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.


[jira] Updated: (SHINDIG-57) gadgets.io.makeRequest does not pass a content-type on POST requests

Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
     [ 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.


[jira] Closed: (SHINDIG-57) gadgets.io.makeRequest does not pass a content-type on POST requests

Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SHINDIG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Brown closed SHINDIG-57.
------------------------------

    Resolution: Fixed

Committed

> 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
>
>
> 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.


[jira] Commented: (SHINDIG-57) gadgets.io.makeRequest does not pass a content-type on POST requests

Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SHINDIG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567367#action_12567367 ] 

Kevin Brown commented on SHINDIG-57:
------------------------------------

POST requests aren't always necessarily application/x-www-form-urlencoded. That's only when you're dealing with form encoded key-value pairs.

We should pass through the content type headers, but forcing www-form-urlencoded is no the right way to go because we still need to support other request types (especially for RPC servers).

Until this can be dropped in, a workaround for php is to manually parse the post data as follows:

$postData = file_get_contents('php://input');

$values = explode('&',$postData);

for ($i = 0, $j = count($values); $i <  $j; $i += 2) {
  $_POST[$values[$i]] = $values[$i + 1];
}

I'll drop in a patch to correctly pass through headers shortly.

> 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
>
>
> 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.


[jira] Updated: (SHINDIG-57) gadgets.io.makeRequest does not pass a content-type on POST requests

Posted by "Arne Roomann-Kurrik (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SHINDIG-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Arne Roomann-Kurrik updated SHINDIG-57:
---------------------------------------

    Attachment: add-content-type.patch.txt

I used this patch to be able to make a request to a third party server with the correct Content-Type header.  There may be a better/more flexible solution, however.

> 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
>
>
> 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.