586032 - Recent changes broke submitting comments (possibly more)

Status: RESOLVED WONTFIX

(Webtools Graveyard :: BzAPI, defect)

Description

[Shawn Wilsher :sdwilsh]

It used to be the case that this would work:

POST /latest/bug/582201/comment?username=[e-mail]&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.

Comment 1

[Gervase Markham [:gerv]]

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

Comment 2

[Shawn Wilsher :sdwilsh]

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

Comment 3

[Gervase Markham [:gerv]]

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

Comment 4

[Gervase Markham [:gerv]]

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

Comment 5

[Shawn Wilsher :sdwilsh]

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