unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Hongli Lai <hongli@phusion.nl>
To: Michael Fischer <mfischer@zendesk.com>
Cc: Gary Grossman <gary.grossman@gmail.com>, Eric Wong <e@80x24.org>,
	 unicorn-public <unicorn-public@bogomips.org>,
	Michael Grosser <michael@grosser.it>
Subject: Re: Please move to github
Date: Mon, 4 Aug 2014 09:22:21 +0200	[thread overview]
Message-ID: <CAM3ce8GnCGaODj0SptDW2cTF_cQQS1eBZH1n5E5Xs7J_0DL8Zw@mail.gmail.com> (raw)
In-Reply-To: <CABHxtY6PLE71oDYvVviPtsLckJUU+DxmMe+X_V8iOOfcpcq7Nw@mail.gmail.com>

On Sat, Aug 2, 2014 at 9:33 PM, Michael Fischer <mfischer@zendesk.com> wrote:
> On Sat, Aug 2, 2014 at 12:07 PM, Gary Grossman <gary.grossman@gmail.com>
> wrote:
>> This might be one of those instances where it would be helpful for
>> implementation to lead specification. Unicorn is one of the leading
>> servers of its genre, if not the leader. If you supported a switch
>> that made the encoding regime more sane, I think other popular servers
>> like Thin and Passenger would swiftly follow and it might re-energize
>> the discussion about getting encodings into the Rack spec once and
>> for all, and give a base for experimentation and iteration for
>> getting the encodings in the spec right.
>>
>
> I agree with Gary here.  It's often too easy to decide to preserve the
> status quo because things work well enough -- and then, eventually, time
> catches up with you and it no longer does.

Hi guys. Phusion Passenger author here. I would very much support
standardization of encoding issues. Every now and then, a user submits
a bug report on Phusion Passenger, mentioning an encoding problem. The
user would say that the problem occurs on Phusion Passenger but not on
Unicorn/Thin/etc. The Rack spec doesn't say anything about encodings
so strictly speaking it's not "our fault", but it's still hard to tell
users that it's "their fault" or "their framework's fault" based on
this alone. It's also not a helpful answer: users often have no idea
what to do about the issue.

At this point, I don't really care what the standard is, as long as
it's a sane standard that everybody can follow.

In my opinion, following Encoding.default_external is not helpful.
Most users have absolutely no idea how to configure
Encoding.default_external, or even know that it exists. I've also
never, ever seen anybody who does *not* want default_external to be
UTF-8. If it's not set to UTF-8, then it's always by accident (e.g.
the user not knowing that it depends on LC_CTYPE, that LC_CTYPE is set
differently in the shell than from an init script, or even what
LC_CTYPE is).

-- 
Phusion | Web Application deployment, scaling, and monitoring solutions

Web: http://www.phusion.nl/
E-mail: info@phusion.nl
Chamber of commerce no: 08173483 (The Netherlands)

  reply	other threads:[~2014-08-04  7:23 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-02  7:51 Please move to github Gary Grossman
2014-08-02  7:54 ` Kapil Israni
2014-08-02  8:02   ` Eric Wong
2014-08-02  8:50 ` Eric Wong
2014-08-02 19:07   ` Gary Grossman
2014-08-02 19:33     ` Michael Fischer
2014-08-04  7:22       ` Hongli Lai [this message]
2014-08-04  8:48         ` Rack encodings (was: Please move to github) Eric Wong
2014-08-04  9:46           ` Hongli Lai
2014-08-02 20:15     ` Please move to github Eric Wong
  -- strict thread matches above, loose matches on Subject: below --
2014-08-02  7:46 Gary Grossman
2014-08-01 22:32 Victor Kmita
2014-08-01 20:27 Michael Grosser
2014-08-01 21:32 ` Eric Wong
2014-08-01 22:27   ` Michael Grosser
2014-08-01 22:41     ` Eric Wong
     [not found]       ` <CAAms34NByMcXnbGQ3DvCZTsQuh6yBn8sMSNeTi7Ss4VmmYoOrQ@mail.gmail.com>
2014-08-01 23:07         ` Eric Wong
2014-08-01 22:48     ` Gabe da Silveira
2014-08-01 23:09       ` Xavier Noria
2014-08-01 23:12         ` Michael Grosser
2014-08-01 23:24           ` Eric Wong
2014-08-01 23:26           ` Daniel Evans
2014-08-01 23:38             ` Michael Grosser
2014-08-01 23:18         ` Aaron Suggs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://yhbt.net/unicorn/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAM3ce8GnCGaODj0SptDW2cTF_cQQS1eBZH1n5E5Xs7J_0DL8Zw@mail.gmail.com \
    --to=hongli@phusion.nl \
    --cc=e@80x24.org \
    --cc=gary.grossman@gmail.com \
    --cc=mfischer@zendesk.com \
    --cc=michael@grosser.it \
    --cc=unicorn-public@bogomips.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhbt.net/unicorn.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).