Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Can't POST with JSON-RPC
614 views
Skip to first unread message
Evan Oman
Jun 15, 2012, 9:22:48 AM6/15/12
to
Hey, I'm having this problem when I'm posting data to the Bugzilla API
using JSONRPC.
I'm able to get data (successes with Bug.get, Bugzilla.time) from
Bugzilla no problem. But when I try to save data (Bug.add_comment/
Bug.update/User.login) I get various messages back saying "For
security reasons, you must use HTTP POST to call the 'User.login'
method.","code":32610.
I am using HTTP POST! I'm using a php backend and cURL to post data.
I've tested out on another page to make sure there's nothing in GET
and it's all in POST, and that's true. I am using Bugzilla version
4.2 and interfacing with the http://landfill.bugzilla.org/bugzilla-4.2-branch/jsonrpc.cgi.
Is there something in that Bugzilla's configuration that might prevent
these calls from working?
Is the JSONRPC still that unstable? Am I doing something wrong? Is
there extra data that I should be sending that a newbie might miss?
Here is my ajax call:
$.ajax({
url: "ajax_modify_bug.php",
type: "POST",
data: {
"bug_id": 1294,
"priority": "P3"
},
dataType: "json",
success: function(data, status){
if (data.error)
{
alert(data.error.message);
}
else if (!data.result)
{
alert("Something is wrong");
}
else
{
//Will eventually hold the card.data map below. Need to make the Bug.Update work first
}
},
error: function(jqXHR, textStatus, errorThrown){
alert("There was an error:" + textStatus);
}
});
And here is my associated PHP script:
<?php
include "config.php";
$bugId = filter_input(INPUT_POST, "bug_id", FILTER_SANITIZE_NUMBER_INT);
$priority = filter_input(INPUT_POST, "priority", FILTER_SANITIZE_STRING);
$params = array(array("Bugzilla_login" => "username", "Bugzilla_password" => "password", "ids"=> $bugId, "priority" => $priority));
$params = json_encode($params);
$data = array("method" => "Bug.update", "params" => $params);
// is cURL installed yet?
if (!function_exists('curl_init')) {
die('Sorry cURL is not installed!');
}
// OK cool - then let's create a new cURL resource handle
$ch = curl_init();
// Now set some options (most are optional)
// Set URL to download
curl_setopt($ch, CURLOPT_URL, BUGZILLA_URL);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
// Include header in result? (1 = yes, 0 = no)
curl_setopt($ch, CURLOPT_HEADER, 0);
// Should cURL return or print out the data? (true = return, false = print)
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
// Timeout in seconds
curl_setopt($ch, CURLOPT_TIMEOUT, 10);
// Download the given URL, and return output
$output = curl_exec($ch);
if($output === false)
{
echo json_encode(array("error" => array("message"=>'Curl error: ' . curl_error($ch))));
}
else
{
echo $output;
}
// Close the cURL resource, and free system resources
curl_close($ch);
?>
Thanks for your help.
using JSONRPC.
I'm able to get data (successes with Bug.get, Bugzilla.time) from
Bugzilla no problem. But when I try to save data (Bug.add_comment/
Bug.update/User.login) I get various messages back saying "For
security reasons, you must use HTTP POST to call the 'User.login'
method.","code":32610.
I am using HTTP POST! I'm using a php backend and cURL to post data.
I've tested out on another page to make sure there's nothing in GET
and it's all in POST, and that's true. I am using Bugzilla version
4.2 and interfacing with the http://landfill.bugzilla.org/bugzilla-4.2-branch/jsonrpc.cgi.
Is there something in that Bugzilla's configuration that might prevent
these calls from working?
Is the JSONRPC still that unstable? Am I doing something wrong? Is
there extra data that I should be sending that a newbie might miss?
Here is my ajax call:
$.ajax({
url: "ajax_modify_bug.php",
type: "POST",
data: {
"bug_id": 1294,
"priority": "P3"
},
dataType: "json",
success: function(data, status){
if (data.error)
{
alert(data.error.message);
}
else if (!data.result)
{
alert("Something is wrong");
}
else
{
//Will eventually hold the card.data map below. Need to make the Bug.Update work first
}
},
error: function(jqXHR, textStatus, errorThrown){
alert("There was an error:" + textStatus);
}
});
And here is my associated PHP script:
<?php
include "config.php";
$bugId = filter_input(INPUT_POST, "bug_id", FILTER_SANITIZE_NUMBER_INT);
$priority = filter_input(INPUT_POST, "priority", FILTER_SANITIZE_STRING);
$params = array(array("Bugzilla_login" => "username", "Bugzilla_password" => "password", "ids"=> $bugId, "priority" => $priority));
$params = json_encode($params);
$data = array("method" => "Bug.update", "params" => $params);
// is cURL installed yet?
if (!function_exists('curl_init')) {
die('Sorry cURL is not installed!');
}
// OK cool - then let's create a new cURL resource handle
$ch = curl_init();
// Now set some options (most are optional)
// Set URL to download
curl_setopt($ch, CURLOPT_URL, BUGZILLA_URL);
curl_setopt($ch, CURLOPT_FOLLOWLOCATION, true);
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
// Include header in result? (1 = yes, 0 = no)
curl_setopt($ch, CURLOPT_HEADER, 0);
// Should cURL return or print out the data? (true = return, false = print)
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
// Timeout in seconds
curl_setopt($ch, CURLOPT_TIMEOUT, 10);
// Download the given URL, and return output
$output = curl_exec($ch);
if($output === false)
{
echo json_encode(array("error" => array("message"=>'Curl error: ' . curl_error($ch))));
}
else
{
echo $output;
}
// Close the cURL resource, and free system resources
curl_close($ch);
?>
Thanks for your help.
Thorsten Schöning
Jun 15, 2012, 10:09:13 AM6/15/12
to support-...@lists.mozilla.org
Guten Tag Evan Oman,
am Freitag, 15. Juni 2012 um 15:22 schrieben Sie:
> But when I try to save data (Bug.add_comment/
> Bug.update/User.login) I get various messages back saying "For
> security reasons, you must use HTTP POST to call the 'User.login'
> method.","code":32610.
This error is thrown in Bugzilla:.WebService::Server::JSONRPC line
385:
if ($self->request->method eq 'POST') {
# CSRF is possible via XMLHttpRequest when the Content-Type header
# is not application/json (for example: text/plain or
# application/x-www-form-urlencoded).
# application/json is the single official MIME type, per RFC 4627.
my $content_type = $self->cgi->content_type;
# The charset can be appended to the content type, so we use a regexp.
if ($content_type !~ m{^application/json(-rpc)?(;.*)?$}i) {
ThrowUserError('json_rpc_illegal_content_type',
{ content_type => $content_type });
}
}
else {
# When being called using GET, we don't allow calling
# methods that can change data. This protects us against cross-site
# request forgeries.
if (!grep($_ eq $method, $pkg->READ_ONLY)) {
ThrowUserError('json_rpc_post_only',
{ method => $self->_bz_method_name });
}
}
This looks fairly simple to me, if you are really sure that you send
POST, and from your cURL options I would agree that you do use POST,
you should debug Bugzilla and look what $self->request->method is in
your case and maybe find a hint why it is not what you would expect it
to be.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten....@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
am Freitag, 15. Juni 2012 um 15:22 schrieben Sie:
> But when I try to save data (Bug.add_comment/
> Bug.update/User.login) I get various messages back saying "For
> security reasons, you must use HTTP POST to call the 'User.login'
> method.","code":32610.
385:
if ($self->request->method eq 'POST') {
# CSRF is possible via XMLHttpRequest when the Content-Type header
# is not application/json (for example: text/plain or
# application/x-www-form-urlencoded).
# application/json is the single official MIME type, per RFC 4627.
my $content_type = $self->cgi->content_type;
# The charset can be appended to the content type, so we use a regexp.
if ($content_type !~ m{^application/json(-rpc)?(;.*)?$}i) {
ThrowUserError('json_rpc_illegal_content_type',
{ content_type => $content_type });
}
}
else {
# When being called using GET, we don't allow calling
# methods that can change data. This protects us against cross-site
# request forgeries.
if (!grep($_ eq $method, $pkg->READ_ONLY)) {
ThrowUserError('json_rpc_post_only',
{ method => $self->_bz_method_name });
}
}
This looks fairly simple to me, if you are really sure that you send
POST, and from your cURL options I would agree that you do use POST,
you should debug Bugzilla and look what $self->request->method is in
your case and maybe find a hint why it is not what you would expect it
to be.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten....@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon.............030-2 1001-310
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hanover HRB 207 694 - Geschäftsführer: Andreas Muchow
Message has been deleted
Message has been deleted
Evan Oman
Jun 15, 2012, 10:32:51 AM6/15/12
to
> This looks fairly simple to me, if you are really sure that you send
> POST, and from your cURL options I would agree that you do use POST,
> you should debug Bugzilla and look what $self->request->method is in
> your case and maybe find a hint why it is not what you would expect it
> to be.
Hey thanks for the fast response. How would I go about debugging the landfill server? I am very new to all of this so any help would be awesome.
> POST, and from your cURL options I would agree that you do use POST,
> you should debug Bugzilla and look what $self->request->method is in
> your case and maybe find a hint why it is not what you would expect it
> to be.
Thorsten Schöning
Jun 15, 2012, 11:05:56 AM6/15/12
to support-...@lists.mozilla.org
Guten Tag Evan Oman,
am Freitag, 15. Juni 2012 um 16:19 schrieben Sie:
> Hey thanks for the fast response. How would I go about debugging
> the landfill server? I am very new to all of this so any help would be awesome.
You can't, I thought you have your own instance of Bugzilla running.
In your case the only thing I could think of is Wireshark with
non-https communication, if it is possible with landfill. I don't
think the problem is within Bugzilla itself, you could post Wireshark
logs here so we can have a look.
am Freitag, 15. Juni 2012 um 16:19 schrieben Sie:
> Hey thanks for the fast response. How would I go about debugging
> the landfill server? I am very new to all of this so any help would be awesome.
In your case the only thing I could think of is Wireshark with
non-https communication, if it is possible with landfill. I don't
think the problem is within Bugzilla itself, you could post Wireshark
logs here so we can have a look.
Evan Oman
Jun 15, 2012, 1:11:46 PM6/15/12
to support-...@lists.mozilla.org
> You can't, I thought you have your own instance of Bugzilla running.
> In your case the only thing I could think of is Wireshark with
> non-https communication, if it is possible with landfill. I don't
> think the problem is within Bugzilla itself, you could post Wireshark
> logs here so we can have a look.
>
I'm not sure I did this right but here is what wireshark got out of my request:
> In your case the only thing I could think of is Wireshark with
> non-https communication, if it is possible with landfill. I don't
> think the problem is within Bugzilla itself, you could post Wireshark
> logs here so we can have a look.
>
No. Time Source Destination Protocol Length Info
17 2.386098 192.168.0.19 50.116.97.188 HTTP 804 POST /evan/ajax_modify_bug.php HTTP/1.1 (application/x-www-form-urlencoded)
Frame 17: 804 bytes on wire (6432 bits), 804 bytes captured (6432 bits)
Ethernet II, Src: Giga-Byt_ee:62:a3 (50:e5:49:ee:62:a3), Dst: Actionte_f2:be:ec (00:26:b8:f2:be:ec)
Destination: Actionte_f2:be:ec (00:26:b8:f2:be:ec)
Address: Actionte_f2:be:ec (00:26:b8:f2:be:ec)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: Giga-Byt_ee:62:a3 (50:e5:49:ee:62:a3)
Address: Giga-Byt_ee:62:a3 (50:e5:49:ee:62:a3)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.0.19 (192.168.0.19), Dst: 50.116.97.188 (50.116.97.188)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
Total Length: 790
Identification: 0x1d4e (7502)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (6)
Header checksum: 0x0000 [incorrect, should be 0x85a8 (maybe caused by "IP checksum offload"?)]
Source: 192.168.0.19 (192.168.0.19)
Destination: 50.116.97.188 (50.116.97.188)
Transmission Control Protocol, Src Port: 53149 (53149), Dst Port: http (80), Seq: 1, Ack: 1, Len: 750
Hypertext Transfer Protocol
POST /evan/ajax_modify_bug.php HTTP/1.1\r\n
[Expert Info (Chat/Sequence): POST /evan/ajax_modify_bug.php HTTP/1.1\r\n]
Request Method: POST
Request URI: /evan/ajax_modify_bug.php
Request Version: HTTP/1.1
Host: www.eckop.com\r\n
Connection: keep-alive\r\n
Content-Length: 23\r\n
[Content length: 23]
Origin: http://www.eckop.com\r\n
X-Requested-With: XMLHttpRequest\r\n
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5\r\n
Content-Type: application/x-www-form-urlencoded; charset=UTF-8\r\n
Accept: application/json, text/javascript, */*; q=0.01\r\n
Referer: http://www.eckop.com/evan/Index.html\r\n
Accept-Encoding: gzip,deflate,sdch\r\n
Accept-Language: en-US,en;q=0.8\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3\r\n
Cookie: __utma=218965133.1161481950.1338909823.1339420263.1339614975.3; __utmz=218965133.1338909823.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)\r\n
\r\n
[Full request URI: http://www.eckop.com/evan/ajax_modify_bug.php]
Line-based text data: application/x-www-form-urlencoded
bug_id=1294&priority=P3
And here is Bugzilla's response:
No. Time Source Destination Protocol Length Info
18 2.447294 50.116.97.188 192.168.0.19 TCP 60 http > 53149 [ACK] Seq=1 Ack=751 Win=16128 Len=0
Frame 18: 60 bytes on wire (480 bits), 60 bytes captured (480 bits)
Ethernet II, Src: Actionte_f2:be:ec (00:26:b8:f2:be:ec), Dst: Giga-Byt_ee:62:a3 (50:e5:49:ee:62:a3)
Destination: Giga-Byt_ee:62:a3 (50:e5:49:ee:62:a3)
Address: Giga-Byt_ee:62:a3 (50:e5:49:ee:62:a3)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: Actionte_f2:be:ec (00:26:b8:f2:be:ec)
Address: Actionte_f2:be:ec (00:26:b8:f2:be:ec)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Trailer: 000000000000
Internet Protocol Version 4, Src: 50.116.97.188 (50.116.97.188), Dst: 192.168.0.19 (192.168.0.19)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
Total Length: 40
Identification: 0xd7bd (55229)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 56
Protocol: TCP (6)
Header checksum: 0x1627 [correct]
Source: 50.116.97.188 (50.116.97.188)
Destination: 192.168.0.19 (192.168.0.19)
Transmission Control Protocol, Src Port: http (80), Dst Port: 53149 (53149), Seq: 1, Ack: 751, Len: 0
Sorry about the mess, I hope this is what you were asking for
Evan Oman
Jun 15, 2012, 1:33:46 PM6/15/12
to support-...@lists.mozilla.org
> I'm not sure I did this right but here is what wireshark got out of my request:
>
Except now that I look at it, it looks like 50.116.97.188 is the IP of the server that my php file is hosted on, not the Landfill server like I thought it was. Not sure what that means...
>
Evan Oman
Jun 15, 2012, 10:19:26 AM6/15/12
to mozilla.supp...@googlegroups.com, support-...@lists.mozilla.org
> This looks fairly simple to me, if you are really sure that you send
> POST, and from your cURL options I would agree that you do use POST,
> you should debug Bugzilla and look what $self->request->method is in
> your case and maybe find a hint why it is not what you would expect it
> to be.
> POST, and from your cURL options I would agree that you do use POST,
> you should debug Bugzilla and look what $self->request->method is in
> your case and maybe find a hint why it is not what you would expect it
> to be.
Message has been deleted
Message has been deleted
wayne...@ints.com
Jun 15, 2012, 2:09:58 PM6/15/12
to
$data = array("method" => "Bug.update", "params" => $params, "id" => "1");
See: http://json-rpc.org/wiki/specification
Wayne
Evan Oman
Jun 15, 2012, 2:47:04 PM6/15/12
to
> You need to include the "id" field.
>
> $data = array("method" => "Bug.update", "params" => $params, "id" => "1");
>
> See: http://json-rpc.org/wiki/specification
>
> Wayne
wa...@devzing.com
Jun 15, 2012, 3:06:51 PM6/15/12
to
id - The request id. This can be of any type. It is used to match the response with the request that it is replying to.
For what you are doing it doesn't matter what the value it, but it is a mandatory field.
Wayne
Evan Oman
Jun 15, 2012, 3:09:58 PM6/15/12
to
> Did you look at the link to the json-rpc spec?
>
> id - The request id. This can be of any type. It is used to match the response with the request that it is replying to.
>
> For what you are doing it doesn't matter what the value it, but it is a mandatory field.
>
> Wayne
Thorsten Schöning
Jun 15, 2012, 3:35:20 PM6/15/12
to support-...@lists.mozilla.org
Guten Tag Evan Oman,
am Freitag, 15. Juni 2012 um 19:33 schrieben Sie:
> Except now that I look at it, it looks like 50.116.97.188 is the IP
> of the server that my php file is hosted on, not the Landfill server
> like I thought it was. Not sure what that means...
It means your Wireshark excerpt is useless because it only covers your
own AJAX communication and not the one from your PHP to whatever
Bugzilla instance you use. But that's the only interesting part of
your problem. Host your PHP script locally to trace the communication
or log communication on the server you use or something else. There
surely is something wrong with your request.
am Freitag, 15. Juni 2012 um 19:33 schrieben Sie:
> Except now that I look at it, it looks like 50.116.97.188 is the IP
> of the server that my php file is hosted on, not the Landfill server
> like I thought it was. Not sure what that means...
own AJAX communication and not the one from your PHP to whatever
Bugzilla instance you use. But that's the only interesting part of
your problem. Host your PHP script locally to trace the communication
or log communication on the server you use or something else. There
surely is something wrong with your request.
Evan Oman
Jun 15, 2012, 4:12:57 PM6/15/12
to support-...@lists.mozilla.org
Thorsten Schöning
Jun 16, 2012, 3:55:20 AM6/16/12
to support-...@lists.mozilla.org
Guten Tag Evan Oman,
am Freitag, 15. Juni 2012 um 22:12 schrieben Sie:
> Alright I hosted the PHP locally and was able to capture all of the
> traffic between my machine and the Bugzilla server. Now what I am I
> looking for specifically? What should I post for you to look at?
Look for the one request for Bug.update(?) you are trying to make,
this one covers all needed information: HTTP method, sent data etc. It
should be somewhere right after your AJAX call and before you AJAX
call get its answer.
am Freitag, 15. Juni 2012 um 22:12 schrieben Sie:
> Alright I hosted the PHP locally and was able to capture all of the
> traffic between my machine and the Bugzilla server. Now what I am I
> looking for specifically? What should I post for you to look at?
this one covers all needed information: HTTP method, sent data etc. It
should be somewhere right after your AJAX call and before you AJAX
call get its answer.
Evan Oman
Jun 18, 2012, 9:21:46 AM6/18/12
to support-...@lists.mozilla.org
No. Time Source Destination Protocol Length Info
Frame 7: 494 bytes on wire (3952 bits), 494 bytes captured (3952 bits)
Ethernet II, Src: Giga-Byt_ee:62:a3 (50:e5:49:ee:62:a3), Dst: Actionte_f2:be:ec (00:26:b8:f2:be:ec)
Internet Protocol Version 4, Src: 192.168.0.19 (192.168.0.19), Dst: 63.245.223.28 (63.245.223.28)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
Total Length: 480
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
Identification: 0x1d11 (7441)
Flags: 0x02 (Don't Fragment)
Fragment offset: 0
Time to live: 128
Protocol: TCP (6)
Header checksum: 0x0000 [incorrect, should be 0xfc39 (maybe caused by "IP checksum offload"?)]
Fragment offset: 0
Time to live: 128
Protocol: TCP (6)
Source: 192.168.0.19 (192.168.0.19)
Destination: 63.245.223.28 (63.245.223.28)
Transmission Control Protocol, Src Port: 49654 (49654), Dst Port: http (80), Seq: 222, Ack: 26, Len: 440
Source port: 49654 (49654)
Destination port: http (80)
[Stream index: 0]
Sequence number: 222 (relative sequence number)
[Next sequence number: 662 (relative sequence number)]
Acknowledgement number: 26 (relative ack number)
Header length: 20 bytes
Flags: 0x018 (PSH, ACK)
Window size value: 257
[Calculated window size: 65792]
[Window size scaling factor: 256]
Checksum: 0xe19f [validation disabled]
[SEQ/ACK analysis]
TCP segment data (440 bytes)
[2 Reassembled TCP Segments (661 bytes): #4(221), #7(440)]
Hypertext Transfer Protocol
POST /bugzilla-4.2-branch/jsonrpc.cgi HTTP/1.1\r\n
[Expert Info (Chat/Sequence): POST /bugzilla-4.2-branch/jsonrpc.cgi HTTP/1.1\r\n]
[Message: POST /bugzilla-4.2-branch/jsonrpc.cgi HTTP/1.1\r\n]
[Severity level: Chat]
[Group: Sequence]
Request Method: POST
Request URI: /bugzilla-4.2-branch/jsonrpc.cgi
Request Version: HTTP/1.1
Host: landfill.bugzilla.org\r\n
Accept: */*\r\n
Content-Length: 440\r\n
Expect: 100-continue\r\n
Content-Type: multipart/form-data; boundary=----------------------------37e3585fa201\r\n
\r\n
[Full request URI: http://landfill.bugzilla.org/bugzilla-4.2-branch/jsonrpc.cgi]
MIME Multipart Media Encapsulation, Type: multipart/form-data, Boundary: "----------------------------37e3585fa201"
And here I think is the actual data being sent, looks right to me:
0000 00 26 b8 f2 be ec 50 e5 49 ee 62 a3 08 00 45 00 .&....P. I.b...E.
0010 01 e0 1d 11 40 00 80 06 00 00 c0 a8 00 13 3f f5 ....@... ......?.
0020 df 1c c1 f6 00 50 01 74 09 ea f2 d1 07 5f 50 18 .....P.t ....._P.
0030 01 01 e1 9f 00 00 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d ......-- --------
0040 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d -------- --------
0050 2d 2d 2d 2d 33 37 65 33 35 38 35 66 61 32 30 31 ----37e3 585fa201
0060 0d 0a 43 6f 6e 74 65 6e 74 2d 44 69 73 70 6f 73 ..Conten t-Dispos
0070 69 74 69 6f 6e 3a 20 66 6f 72 6d 2d 64 61 74 61 ition: f orm-data
0080 3b 20 6e 61 6d 65 3d 22 6d 65 74 68 6f 64 22 0d ; name=" method".
0090 0a 0d 0a 42 75 67 2e 75 70 64 61 74 65 0d 0a 2d ...Bug.u pdate..-
00a0 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d -------- --------
00b0 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 33 37 65 -------- -----37e
00c0 33 35 38 35 66 61 32 30 31 0d 0a 43 6f 6e 74 65 3585fa20 1..Conte
00d0 6e 74 2d 44 69 73 70 6f 73 69 74 69 6f 6e 3a 20 nt-Dispo sition:
00e0 66 6f 72 6d 2d 64 61 74 61 3b 20 6e 61 6d 65 3d form-dat a; name=
00f0 22 70 61 72 61 6d 73 22 0d 0a 0d 0a 5b 7b 22 42 "params" ....[{"B
0100 75 67 7a 69 6c 6c 61 5f 6c 6f 67 69 6e 22 3a 22 ugzilla_ login":"
0110 64 72 2e 65 63 6b 73 6b 40 67 6d 61 69 6c 2e 63 email @gmail.c
0120 6f 6d 22 2c 22 42 75 67 7a 69 6c 6c 61 5f 70 61 om","Bug zilla_pa
0130 73 73 77 6f 72 64 22 3a 22 6b 61 6e 62 61 6e 22 ssword": "pass"
0140 2c 22 69 64 73 22 3a 22 31 32 39 34 22 2c 22 70 ,"ids":" 1294","p
0150 72 69 6f 72 69 74 79 22 3a 22 50 33 22 7d 5d 0d riority" :"P3"}].
0160 0a 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d .------- --------
0170 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 33 -------- -------3
0180 37 65 33 35 38 35 66 61 32 30 31 0d 0a 43 6f 6e 7e3585fa 201..Con
0190 74 65 6e 74 2d 44 69 73 70 6f 73 69 74 69 6f 6e tent-Dis position
01a0 3a 20 66 6f 72 6d 2d 64 61 74 61 3b 20 6e 61 6d : form-d ata; nam
01b0 65 3d 22 69 64 22 0d 0a 0d 0a 62 75 67 73 0d 0a e="id".. ..bugs..
01c0 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d -------- --------
01d0 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 2d 33 37 -------- ------37
01e0 65 33 35 38 35 66 61 32 30 31 2d 2d 0d 0a e3585fa2 01--..
Thanks!
Evan Oman
Jun 18, 2012, 9:54:58 AM6/18/12
to support-...@lists.mozilla.org
> Header checksum: 0x0000 [incorrect, should be 0xfc39 (maybe caused by "IP > checksum offload"?)]
Thorsten Schöning
Jun 18, 2012, 11:18:54 AM6/18/12
to support-...@lists.mozilla.org
Guten Tag Evan Oman,
am Montag, 18. Juni 2012 um 15:54 schrieben Sie:
> This was the one line that caught my attention, the only blatant error that I was able to find.
Ignore that, the HTTP method seems to be OK, I've no idea why you get
the error that POST is required. The only thing left I would do is
test with my own Bugzilla instance and see how $self->request->method
looks like. Something like the following in
Bugzilla::WebServer::JSONRPC around line 366.
}
Bugzilla->input_params($params);
use Data::Dumper;
warn($self->request->method);
warn(Dumper($self->request));
if ($self->request->method eq 'POST') {
am Montag, 18. Juni 2012 um 15:54 schrieben Sie:
> This was the one line that caught my attention, the only blatant error that I was able to find.
the error that POST is required. The only thing left I would do is
test with my own Bugzilla instance and see how $self->request->method
looks like. Something like the following in
Bugzilla::WebServer::JSONRPC around line 366.
}
Bugzilla->input_params($params);
use Data::Dumper;
warn($self->request->method);
warn(Dumper($self->request));
if ($self->request->method eq 'POST') {
Evan Oman
Jun 19, 2012, 12:25:24 PM6/19/12
to support-...@lists.mozilla.org
Thorsten Schöning
Jun 19, 2012, 2:55:12 PM6/19/12
to support-...@lists.mozilla.org
Guten Tag Evan Oman,
am Dienstag, 19. Juni 2012 um 18:25 schrieben Sie:
> Alright would that require that I install my own Bugzilla?
Yes.
> There is
> absolutely no way to do the above debugging with the Lanffill server?
None I'm aware of, you would need a shell access to change the files
and I doubt you're gonna get that one easier than installing you own
instance. ;-) As nobody else seem to have any idea about your problem,
I see no other way to look deeper into your problem.
http://www.bugzilla.org/docs/4.2/en/html/installation.html
am Dienstag, 19. Juni 2012 um 18:25 schrieben Sie:
> Alright would that require that I install my own Bugzilla?
> There is
> absolutely no way to do the above debugging with the Lanffill server?
and I doubt you're gonna get that one easier than installing you own
instance. ;-) As nobody else seem to have any idea about your problem,
I see no other way to look deeper into your problem.
http://www.bugzilla.org/docs/4.2/en/html/installation.html
Evan Oman
Jun 25, 2012, 5:18:02 PM6/25/12
to support-...@lists.mozilla.org
Yeah I couldn't get my local install to cooperate for some reason so I was unable to debug.
Well as a last ditch effort I tried posting over XML and it worked beautifully. The only problem was that the response for a simple Bug.get call was 1500 line jumble of <tag> nonsense which was hard to deal with in JQUERY. What we ended up doing was writing/modifying a parser to convert the response from XML to PHP and then to JSON so my existing JSON parsing in the JQUERY would still work. It works like a charm and I am now able to get, update, search, login, and create as much as I want. Lesson learned: XMLRPC is apparently the more stable of the two access methods. I still have no idea why JSON wasn't working but thank you all for the help, I appreciate it!
Well as a last ditch effort I tried posting over XML and it worked beautifully. The only problem was that the response for a simple Bug.get call was 1500 line jumble of <tag> nonsense which was hard to deal with in JQUERY. What we ended up doing was writing/modifying a parser to convert the response from XML to PHP and then to JSON so my existing JSON parsing in the JQUERY would still work. It works like a charm and I am now able to get, update, search, login, and create as much as I want. Lesson learned: XMLRPC is apparently the more stable of the two access methods. I still have no idea why JSON wasn't working but thank you all for the help, I appreciate it!
0 new messages