Fix barback-server when seeing a non-ascii error string.

Fix barback-server when seeing a non-ascii error string.

BUG=
R=kustermann@google.com

Committed: https://code.google.com/p/dart/source/detail?r=31650

[Anders Johnsen, 2014-01-07 14:19:07]

This should fix it, but I'm not sure this is what you want (it could go up and
be set global).

Let me know.

[nweiz, 2014-01-07 20:11:24]

On 2014/01/07 14:19:07, Anders Johnsen wrote:
> This should fix it, but I'm not sure this is what you want (it could go up and
> be set global).
> 
> Let me know.

Sorry, I just got back from vacation yesterday so I've forgotten a lot of
context. What is this in relation to?

[Anders Johnsen, 2014-01-09 06:00:59]

So, default encoding for HTTP requests is Latin1. We had a bug where the first
'write' would be send as Utf-8, and only the following would be encoded as
Latin1.

With that change, we now get an error when writing a error-message in Russian.
This CL fixed that, however, the content-type could be moved up and set as
'default' content-type, and then overridden later if needed.

[Anders Johnsen, 2014-01-09 09:03:39]

Added a better fix.

[kustermann, 2014-01-09 09:19:11]

LGTM

The comment is from lrn@, don't blame me.

https://codereview.chromium.org/126033002/diff/60001/sdk/lib/_internal/pub/li...
File sdk/lib/_internal/pub/lib/src/barback/server.dart (right):

https://codereview.chromium.org/126033002/diff/60001/sdk/lib/_internal/pub/li...
sdk/lib/_internal/pub/lib/src/barback/server.dart:91: // Set content-type to
force UTF8 encoding.
UTF8 -> UTF-8

[Anders Johnsen, 2014-01-09 09:20:03]

https://codereview.chromium.org/126033002/diff/60001/sdk/lib/_internal/pub/li...
File sdk/lib/_internal/pub/lib/src/barback/server.dart (right):

https://codereview.chromium.org/126033002/diff/60001/sdk/lib/_internal/pub/li...
sdk/lib/_internal/pub/lib/src/barback/server.dart:91: // Set content-type to
force UTF8 encoding.
On 2014/01/09 09:19:12, kustermann wrote:
> UTF8 -> UTF-8

Done.

[Anders Johnsen, 2014-01-09 09:21:35]

Committed patchset #3 manually as r31650 (presubmit successful).

[Bob Nystrom, 2014-01-09 20:58:11]

https://codereview.chromium.org/126033002/diff/130001/sdk/lib/_internal/pub/l...
File sdk/lib/_internal/pub/lib/src/barback/server.dart (right):

https://codereview.chromium.org/126033002/diff/130001/sdk/lib/_internal/pub/l...
sdk/lib/_internal/pub/lib/src/barback/server.dart:93:
ContentType.parse("text/html; charset=utf-8");
Won't this affect anyone doing HTTP in Dart who puts an error message in a
response? Is there a way we can handle this at a lower level in the platform so
other developers benefit too?

[nweiz, 2014-01-09 21:01:27]

https://codereview.chromium.org/126033002/diff/130001/sdk/lib/_internal/pub/l...
File sdk/lib/_internal/pub/lib/src/barback/server.dart (right):

https://codereview.chromium.org/126033002/diff/130001/sdk/lib/_internal/pub/l...
sdk/lib/_internal/pub/lib/src/barback/server.dart:93:
ContentType.parse("text/html; charset=utf-8");
On 2014/01/09 20:58:11, Bob Nystrom wrote:
> Won't this affect anyone doing HTTP in Dart who puts an error message in a
> response? Is there a way we can handle this at a lower level in the platform
so
> other developers benefit too?

If this is only for error-handling, we should move it into [_notFound]. Also,
the content type shouldn't be HTML, since the messages aren't being sent in HTML
(and in fact may have HTML-sensitive characters).

[Anders Johnsen, 2014-01-10 08:52:26]

https://codereview.chromium.org/126033002/diff/130001/sdk/lib/_internal/pub/l...
File sdk/lib/_internal/pub/lib/src/barback/server.dart (right):

https://codereview.chromium.org/126033002/diff/130001/sdk/lib/_internal/pub/l...
sdk/lib/_internal/pub/lib/src/barback/server.dart:93:
ContentType.parse("text/html; charset=utf-8");
On 2014/01/09 20:58:11, Bob Nystrom wrote:
> Won't this affect anyone doing HTTP in Dart who puts an error message in a
> response? Is there a way we can handle this at a lower level in the platform
so
> other developers benefit too?

HTTP requests/responses uses Latin1 by default. That's not something we can
change (it's part of the spec).

However, if you feel like making UTF8 default at a broad level, all you have to
do it set the content-type when you first see the request.

About 'text/html', yes, that may be the wrong mime-type. Depending on what
responses you want to return in UTF-8 (anything with localized errors or paths),
it could be moved accordingly. 

I'll leave it to you to decide where you want it, and what mime-type you prefer.
This CL was mainly for fixing the initial error and getting the tests running
again on the buildbots.