Ticket #1842 (closed enhancement: fixed)

Opened 2 years ago

Last modified 2 years ago

Determination of the right content type for template engines

Reported by: chrisz Assigned to: anonymous
Priority: normal Milestone: 1.5
Component: TurboGears Version: 1.0.4.4
Severity: normal Keywords: TurboJson
Cc:

Description

There are some problems with the determination of the right content type for TurboJson and other template engines (see also ticket #1480).

If no content type is explicitly requested, the generic render() function in view/base.py calls a method get_content_type(user_agent) of the template engine, currently only implemented by TurboJson.

* Issue 1: TurboJson always returns "text/javascript", but nowadays "application/json" should be used. I'd like to change that, and make expose() also understand "application/json". MochiKit also uses that content type in loadJSONDoc.

* Issue 2: There is actually a case destinction for Opera as the user agent, where "text/plain" is returned. But since the user agent is always passed as None due to a bug in view/base.py, this case distinction has never been effective. And I don't know if it was ever needed, surely not for current Opera versions. So I'd like to completely remove that.

* Issue 3: Should get_content_type really be a function? If yes, what input parameters does it need? I think much more important than the user_agent are the accept header and the format parameter. For instance, if format is 'plain', then get_content_type (if implemented in TurboKid, for instance) should return 'text/plain'. Currently we need to set content_type explicitly to 'text/plain'.

* Issue 4: I noticed that the expose decorator gets passed the full Accept header in controller.py. But the Accept header can be a list. Shouldn't we better pass only the first item of that list?

Attachments

preferred_type.py (1.8 kB) - added by chrisz on 06/12/08 18:52:00.
Determination of the preferred media type

Change History

(follow-up: ↓ 2 ) 05/28/08 16:51:21 changed by chrisz

To clarify Issue 4: I actually mean the _expose function, not the expose decorator. It's accept parameter is compared with the accept_format argument of the expose decorator. And with "list" I mean a string with a list of accepted formats like 

text/xml,application/xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5

Wouldn't it make more sense to set accept to text/xml only in this case?

(in reply to: ↑ 1 ) 05/28/08 17:30:54 changed by chrisz

Another and maybe better solution for issue 4 is to parse the accept header into a real list or set, and to replace the comparisons with == in the rules in controllers.py with in operations, i.e. (accept_format in accept instead of accept == accept_format).

06/12/08 03:04:04 changed by chrisz

Concerning the last suggestion for issue 4, this could lead to conflicting rules if more than one mime type is accepted. Also, the format of the accept header is a bit complicated. It can include media ranges and qvalues (see RFC2616). It may be best to reduce the accept header to the most preferred media type (which can be a range, though). For instance 

Accept: text/plain; q=0.5, text/html,
               text/x-dvi; q=0.8, text/x-c

should be reduced to just "text/x-c".

06/12/08 03:30:41 changed by chrisz

The example above should be reduced to "text/html" because that comes first. Both text/html and text/x-c have a qvalue of 1.

Also, a media type of "text/html;level=1" should be reduced to simply "text/html".

06/12/08 06:11:27 changed by chrisz

Concerning issue 4, I've now attached a function for determining the preferred media type, so we can write: accept_format==preferred_type(accept).

06/12/08 18:52:00 changed by chrisz

  • attachment preferred_type.py added.

Determination of the preferred media type

06/12/08 18:53:22 changed by chrisz

Just noticed that a similar function parse_http_accept_header already exists in turbogears.util, but that function returns a list. I improved it a bit (proper handling of whitespace, media range parameters and zero qvalues) and accompanied it with a function simplify_http_accept_header similar to preferred_type (r4715), which is now called before the comparison with accept_format (r4716). This should solve issue 4.

06/13/08 17:00:07 changed by chrisz

  • status changed from new to closed.
  • resolution set to fixed.

Issues 1-3 have now been solved in r4724. The content type is now determined from the format parameter, so that get_content_type gets obsolete. Setting the content type in the response header has been moved from view.render to controllers._process_output, as suggested by ChrisA.