Bug 7498 – Safari/WebKit doesn't recognize encoding returned when saving SN settings in SC

Bug 7498 - Safari/WebKit doesn't recognize encoding returned when saving SN settings in SC

Summary:

Safari/WebKit doesn't recognize encoding returned when saving SN settings in SC

Status:	CLOSED FIXED

Product:	Logitech Media Server
Classification:	Unclassified
Component:	Web Interface
Version:	7.0
Platform:	Macintosh MacOS X 10.5

Importance:	P3 minor (vote)
Target Milestone:	7.x
Assigned To:	Michael Herger

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2008-03-13 02:51 UTC by Michael Herger
Modified:	2009-07-31 10:17 UTC (History)
CC List:	1 user (show)

See Also:
Category:	---

Attachments
Answer forwaded from SN to SC web interface is badly encoded (18.60 KB, image/jpeg) 2008-03-31 09:56 UTC, Michael Herger	Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Michael Herger 2008-03-13 02:51:58 UTC

When saving a setting on that page, it returns an encoding of "UTF-8" (uppercase), which Safari doesn't seem to like, resulting in broken non-latin character display. Same happens in OmniWeb.

I have no idea where this encoding comes from. The other pages are fine (using lowercase utf-8), as is this page on initial load. This only happens when saving. Maybe some oddity in the callback mechanism?

Comment 1 Michael Herger 2008-03-31 09:56:21 UTC

Created attachment 3163 [details]
Answer forwaded from SN to SC web interface is badly encoded

This should read "Änderungen..."

Comment 2 Andy Grundman 2008-04-02 09:24:23 UTC

Might be related to Prototype which is used for the Ajax on that page I think.

Comment 3 Michael Herger 2008-04-02 09:44:01 UTC

There's no JS code loading that page (and Default isn't using prototype any more). AFAICT t's all server side. (Web/Settings/Server/SqueezeNetwork)

Comment 4 Andy Grundman 2008-04-02 10:05:50 UTC

Oh hmm, then I wonder why there are "if (AJAX)" bits in the code.

Comment 5 Michael Herger 2008-04-03 02:51:37 UTC

It rather looks as if the async code didn't add the charset definition to the content-type header

Comment 6 Michael Herger 2008-05-28 05:23:20 UTC

change 20255 - make sure HTML responses from callbacks have the correct charset defined

Comment 7 Chris Owens 2008-07-30 15:30:40 UTC

This bug has now been fixed in the 7.1 release version of SqueezeCenter!  Please download the new version from http://www.slimdevices.com if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.

Comment 8 Chris Owens 2009-07-31 10:17:58 UTC

Reduce number of active targets for SC