872926 - [Buri][Shira-49050] HTTP_ACCEPT_CHARSET is missing

Status: RESOLVED INVALID

(Firefox OS Graveyard :: Gaia::Browser, defect, P2)

Description

[sync-1]

AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.080
 Firefox os  v1.0.1
 Mozilla build ID:20130418070206
 
 +++ This bug was initially created as a clone of Bug #453688 +++
 
 Description: 
 
 Within UA profile, HTTP_ACCEPT_CHARSET information is missing, so web servers can not send content in a proper encoded variant to the device but have to guess and send their standard encoding.
 
 Customer Impact Statement: 
 
 Some web pages might not be displayed correctly if the web server sends them in a wrong encoding due to missing charset information.
 
 Expected Behaviour: 
 
 UA Profile contains HTTP_ACCEPT_CHARSET information.
 
 ________________________________________
 Ding Jiong <jiong.ding>, 5/9/2013:  actually there's no UA PROFILE for the OS. do you mean this issue by missing HTTP_ACCEPT_CHARSET in HEADER, instead of missing in PROFILE?
 ________________________________________
 Tomáš Urban <tomas.urban>, 5/9/2013:  Hi Dennis, could you please comment? Thanks Tom
 ________________________________________
 Tomáš Urban <tomas.urban>, 5/14/2013:  As discussed on the call this issue is HTTP header related. We keep prio 2.
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:
 
 ++++++++++ end of initial bug #453688 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
  DEFECT DESCRIPTION:
 
  REPRODUCING PROCEDURES:
 
  EXPECTED BEHAVIOUR:
 
  ASSOCIATE SPECIFICATION:
 
  TEST PLAN REFERENCE:
 
  TOOLS AND PLATFORMS USED:
 
  USER IMPACT:
 
  REPRODUCING RATE:
 
  For FT PR, Please list reference mobile's behavior:

Comment 1

[Amelie Kong]

AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.019.107
Firefox os  v1.0.1
Mozilla build ID:20130514070202

Comment 2

[Daniel Coloma:dcoloma]

Moving to Mozilla to decide

Comment 3

[Joe Cheng [:jcheng] (please needinfo)]

ni ben? what do you say on this? "this issue is HTTP header related." Thanks

Comment 4

[Masatoshi Kimura [:emk]]

Desktop Firefox doesn't send Accept-Charset either. Nor IE10. How do you decide the charset for them?

> so web servers can not send content in a proper encoded variant

Web servers don't have to send any variants other than utf-8. Why do you quote 5-years-old bug now?

Comment 5

[Masatoshi Kimura [:emk]]

Accept-Charset support has been removed due to a privacy reason (bug 572652).

Comment 6

[Ben Francis [:benfrancis]]

I suggest RESOLVED INVALID/WONTFIX, it doesn't sound like this is a bug.

Comment 7

[Henri Sivonen (:hsivonen)]

Accept-Charset was removed intentionally. It makes no sense anymore, since any site that is capable of producing multiple encodings should always produces UTF-8 these days. Also, Safari and IE don't send it. Chrome is the only browser that sends it anymore.

At this point, this is a server-side bug. When the Accept-Charset header is not present, the server should behave as if it had received Accept-Charset: UTF-8. In general, it makes sense for servers not to check Accept-Charset but to output UTF-8 unconditionally.

Resolved INVALID in the sense "not our bug".

Comment 8

[Henri Sivonen (:hsivonen)]

(In reply to Henri Sivonen (:hsivonen) from comment #7)
> Also, Safari and IE don't send it. Chrome is the
> only browser that sends it anymore.

And it's gone from Chrome as of Chrome 27.