Recent changes broke submitting comments (possibly more)

RESOLVED WONTFIX

Status

Webtools
BzAPI
--
critical
RESOLVED WONTFIX
7 years ago
7 years ago

People

(Reporter: sdwilsh, Assigned: gerv)

Tracking

Trunk
x86
Windows 7

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
It used to be the case that this would work:

POST /latest/bug/582201/comment?username=sdwilsh@forerunnerdesigns.com&password=XXXX HTTP/1.1
Host: api-dev.bugzilla.mozilla.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9pre) Gecko/20100809 Lightning/1.0b2pre Lanikai/3.1.3pre
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8, application/json
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 115
Connection: keep-alive
Content-Length: 110
Content-Type: application/json
Cookie: SSID_AMO=iblCqa0tDugV0EeVT50F;dloadday=63.245.220.240.1274114108066231
Pragma: no-cache
Cache-Control: no-cache
{"is_private":0,"text":"(In reply to comment #11)\u000a> This is a blocker; it does not need approval.\u000a"}


However, now you get the following response from the server:

HTTP/1.1 400 Bad Request Date: Tue, 10 Aug 2010 17:44:09 GMT Server: Apache/2.2.11 (Ubuntu) mod_fastcgi/2.4.6 mod_ssl/2.2.11 OpenSSL/0.9.8g
Content-Length: 42
Connection: close
Content-Type: text/plain
Content-Type text/html is not supported

Making sure that I send this as the "Accept: application/json" makes my add-on work again.  This is a regression from past behavior though, and I was still sending the application/json accept header.
(Assignee)

Comment 1

7 years ago
So your point is that the Accept: header parsing is partly broken, in that it requires a fixed string rather than doing correct header interpretation?

Gerv
(Reporter)

Comment 2

7 years ago
(In reply to comment #1)
> So your point is that the Accept: header parsing is partly broken, in that it
> requires a fixed string rather than doing correct header interpretation?
Yes, that's the jist of it.
(Assignee)

Comment 3

7 years ago
OK, so the application is parsing the Accept header, but the problem is you are putting text/html and application/json into your Accept header with the same priority. The Accept header spec:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
doesn't say that if two types have equal precedence and specificity, the server must pick the first one listed. So the server is entitled to pick text/html, which is not what you want.

There's also another bug, though, which I am tracking down, because text/html should produce some output.

Gerv
(Assignee)

Comment 4

7 years ago
OK, the problem is in Catalyst::Controller::REST's content type choices. What it's doing is trying to use an HTML _de_serializer on the incoming data, which of course won't work, as it's JSON, not HTML. Their content type choosing is broken. However, even if it were fixed, you wouldn't necessarily get what you want from what you are sending anyway. So I suggest you just send the types as suggested in the docs, and all will be well :-)

Gerv
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 5

7 years ago
(In reply to comment #4)
> OK, the problem is in Catalyst::Controller::REST's content type choices. What
> it's doing is trying to use an HTML _de_serializer on the incoming data, which
> of course won't work, as it's JSON, not HTML. Their content type choosing is
> broken. However, even if it were fixed, you wouldn't necessarily get what you
> want from what you are sending anyway. So I suggest you just send the types as
> suggested in the docs, and all will be well :-)
Yeah, I am doing that now, but I filed this mostly to track this change in behavior.  It used to work, and then suddenly stopped.
You need to log in before you can comment on or make changes to this bug.