MSIE and content_types_provided/2

[dvv]

This is what a MSIE9 "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)" browser sends by default:

{<<"accept">>, <<"application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*">>}

My handler defines types:

content_types_provided(Req, State) ->
  {[
    {{<<"text">>, <<"html">>, []}, to_html},
    {{<<"application">>, <<"json">>, []}, to_json},
    {{<<"application">>, <<"vnd.ms-excel">>, []}, to_csv},
    {{<<"text">>, <<"csv">>, []}, to_csv},
    {{<<"text">>, <<"plain">>, []}, to_text}
  ], Req, State}.

and by default to_csv/2 is called instead of expected (least surprise) to_html/2.

How to elevate text/html (which occurs to be just matching a fallback */*)?

[essen]

Not sure what's the best solution. Detecting the browser to return just text/html for IE could work I guess?

Vladimir Dronnikov notifications@github.com wrote:

This is what a MSIE9 "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C)" browser sends by default:

{<<"accept">>, <<"application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, /">>} . My handler defines types:erlang content_types_provided(Req, State) -> {[ {{<<"text">>, <<"html">>, []}, to_html}, {{<<"application">>, <<"json">>, []}, to_json}, {{<<"application">>, <<"vnd.ms-excel">>, []}, to_csv}, {{<<"text">>, <<"csv">>, []}, to_csv}, {{<<"text">>, <<"plain">>, []}, to_text} ], Req, State}.

and by default to_csv/2 is called instead of expected (least surprise) to_html/2.

How to elevate text/html (which occurs to be just matching a fallback /)?

—
Reply to this email directly or view it on GitHub.



[dvv]

I'll try and report to explore what other browsers accept by default.

[dvv]

Chrome gives:

{<<"accept">>, <<"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8">>}

and does work ootb.

[dvv]

Here is a naive workaround -- feedback and thoughts are welcome.

[essen]

Use lists:keyreplace instead.

Vladimir Dronnikov notifications@github.com wrote:

Here is a naive workaround -- feedback and thoughts are welcome.

—
Reply to this email directly or view it on GitHub.



[dvv]

Right, in this case key is supposed to be present in original headers, hence keyreplace won't silently fail to update headers. Thanks

[fishcakez]

I'm not sure what the http spec says but perhaps an interesting idea would be to allow setting priorities for different content types. For example could use a value between 0 and 1 (defaulting to 1). Then multiply this by the accept header q values before deciding on a value.

[fishcakez]

So in this example:

content_types_provided(Req, State) ->
  {[
    {{<<"text">>, <<"html">>, []}, to_html},
    {{<<"application">>, <<"json">>, [], 0.9}, to_json},
    {{<<"application">>, <<"vnd.ms-excel">>, [], 0.9}, to_csv},
    {{<<"text">>, <<"csv">>, [], 0.9}, to_csv},
    {{<<"text">>, <<"plain">>, [], 0.9}, to_text}
  ], Req, State}.

[dvv]

Yes, this might fix the issue without intervention in headers.

[essen]

I don't understand what you propose.

Anyway looking at your issue, I don't think it is IE9 which sends this, and indeed your User-Agent says IE7. Perhaps IE9 on Windows Media Center is fake and is just IE7 with a skin?

I found here (http://blogs.msdn.com/b/fiddler/archive/2011/02/10/fiddler-is-better-with-internet-explorer-9.aspx) that IE9 onward does the right thing, so I don't think we need to add anything in Cowboy to make it work.

[dvv]

It is IE9 in quirks mode.
I do believe cowboy shouldn't care of this issue -- cowboy simply does its best at hypermedia negotiation and would work ok if the client were sane.

[essen]

Ah, quirks mode, I totally forgot this existed.

Closing, thanks!