From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Status: No, score=-2.4 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RCVD_IN_SORBS_SPAM,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 Received: from mail-lf0-f55.google.com (mail-lf0-f55.google.com [209.85.215.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 4591720229 for ; Mon, 24 Oct 2016 12:01:48 +0000 (UTC) Received: by mail-lf0-f55.google.com with SMTP id x79sf1089587lff.1 for ; Mon, 24 Oct 2016 05:01:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=sender:mime-version:in-reply-to:references:from:date:message-id :subject:to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=HSMeL0i7G7QoNGv6KSATj9SGHW6q7vI7jtJBjVRVb/s=; b=G057jm4X+TlBkkjgHplgom7B7NDSpttDopg8o+5oq2PkYhg4L2KoSxLsLjGz/18ZBg Ku5PcaD/M4IPRu/a7cqw5jPWOuytmeeqvdb/wxQr/hpyDqu75WZuu7D5XJAUfJXl+H+e i/WLip8pYzuuqKlQcRsCKRO6WnzxCcEAkg5ZT/7rLy0qMnRSxQO38jP4IIhLfXNKuld1 lViyNwZ1B4v5gvM9ikubrdM/eCvNCRJeSykYA3pIA35AyzQ9H6fWzxtac/Y96KAFHViZ E11JkeZnHsB6lkwBVgIubL85JTR18UQbeL0yz1i726Hp5XrK2hsi8y2m1eCvaPsPVzNS tCBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=HSMeL0i7G7QoNGv6KSATj9SGHW6q7vI7jtJBjVRVb/s=; b=kc9RP/WTqTxVqPXVOncahCMGKwpAHAeMJ/3i6GEPGNfcLixBe4NEgWVnSmISxvnjMu NIa2J7dMB2ZsnhhyVckCDl5wymtRNXW5plE2MNzQGtlZ6w/p+f+UOTWSRyHg7adGlMsX uAx05dGQd+PJAvUktPVj3lPUuU3GRMEWQ2FLk5+o2dSbEYvlC632BGkGyR9UvyiJVl9l wS0hu4WO9qwzwiMtFCGtnnpfVwyyKxCebFvPx4yGTFsy5ngJRV2UyCGLSFMQBbWfPhiH YJJgsgavMF0EJQJwfNttTDkd2jpZytP3+Yj4WLvpHlB1G08/N4rgwKpablepwYQscYxC eMNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=sender:x-gm-message-state:mime-version:in-reply-to:references:from :date:message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=HSMeL0i7G7QoNGv6KSATj9SGHW6q7vI7jtJBjVRVb/s=; b=aA53P3YgwEAhrQCije/+iZReCwVs3hCCoHz0Lk751I2RlywtF5E+ZDeHUPArKVOqll OcsLLfXCK1VfCJ/T+KXpGrpmiyonVPrhvXNcRsa3JvXowfPLplveUoY1VRNYhchf4BMc nd/YnNHLlG7p+F+2aKk6H6HI4QUscG7kkOIarttKnN/bL8fvlUCCUMGRVpYHcY94ot/5 U/R8bejxk4gk9soBGuoMjWWOrpIF3ZsyCQj/hl6jwoG9a9rMYY19VfKwg1cOixGYC6V8 ohHP0+oq3IGvFBoVngkwM1uVfPkslU14dv9QdgMHxmEV5gkA9y2ewrPDJYeqhE1PxD9n 1x/Q== Sender: rack-devel@googlegroups.com X-Gm-Message-State: AA6/9RkxuVPQgdywmIa6ZFc/05Zkt3/v3PHsF+pMSViDgZT/ECQzpmJuKlMegoLnWvSDMw== X-Received: by 10.28.199.207 with SMTP id x198mr170585wmf.19.1477310506413; Mon, 24 Oct 2016 05:01:46 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.28.224.87 with SMTP id x84ls939138wmg.13.canary-gmail; Mon, 24 Oct 2016 05:01:45 -0700 (PDT) X-Received: by 10.28.203.197 with SMTP id b188mr2129874wmg.2.1477310505964; Mon, 24 Oct 2016 05:01:45 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com. [2a00:1450:400c:c09::232]) by gmr-mx.google.com with ESMTPS id g142si613711wmd.2.2016.10.24.05.01.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Oct 2016 05:01:45 -0700 (PDT) Received-SPF: pass (google.com: domain of judofyr@gmail.com designates 2a00:1450:400c:c09::232 as permitted sender) client-ip=2a00:1450:400c:c09::232; Received: by mail-wm0-x232.google.com with SMTP id c78so99147130wme.0 for ; Mon, 24 Oct 2016 05:01:45 -0700 (PDT) X-Received: by 10.28.14.65 with SMTP id 62mr21545632wmo.3.1477310504536; Mon, 24 Oct 2016 05:01:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.34.9 with HTTP; Mon, 24 Oct 2016 05:01:23 -0700 (PDT) In-Reply-To: <6c68f46f-fdc5-4cd3-b36c-9b2c6bf3e03e@googlegroups.com> References: <6c68f46f-fdc5-4cd3-b36c-9b2c6bf3e03e@googlegroups.com> From: Magnus Holm Date: Mon, 24 Oct 2016 14:01:23 +0200 Message-ID: Subject: Re: HTTP_ Headers from clients To: rack-devel Content-Type: multipart/alternative; boundary=001a114427e4d897ea053f9b2747 X-Original-Sender: judofyr@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of judofyr@gmail.com designates 2a00:1450:400c:c09::232 as permitted sender) smtp.mailfrom=judofyr@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Reply-To: rack-devel@googlegroups.com Precedence: list Mailing-list: list rack-devel@googlegroups.com; contact rack-devel+owners@googlegroups.com List-ID: X-Google-Group-Id: 486215384060 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , --001a114427e4d897ea053f9b2747 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Arne, When the client sends a request which looks like this: GET / HTTP/1.1 Host: example.com Company: Acme The server you're using will always create the following environment: { 'HTTP_COMPANY' =3D> 'Acme', 'HTTP_HOST' =3D> 'example.com', =E2=80=A6 } If the client sends a request which looks like this: GET / HTTP/1.1 Host: example.com Http-Company: Acme Then the environment will look like this: { 'HTTP_HTTP_COMPANY' =3D> 'Acme', 'HTTP_HOST' =3D> 'example.com', =E2=80=A6 }. So yes: If you're using Rack directly, you will need to use HTTP_COMPANY on the server-side, and that will correspond to the "Company" header sent from the client. // Magnus Holm On Mon, Oct 24, 2016 at 10:16 AM, Olivar Plays wrote: > Hello, > > I have a small question about the behaviour of Rack when it comes to > headers send by clients. > Are these always prefixed with HTTP_ ? Or do I need to tell my clients to > explicitly send them as HTTP_ ? > > Example, I'm checking on every request in my Rails application whether th= e > HTTP_COMPANY header is present, and has the correct value. > But I've been running into issues with detecting them. > Right now I have the client app send the headers as COMPANY, and my Rails > app checks as HTTP_COMPANY. > Is this the intended behaviour, or will this go wrong again when the > client suddenly submits the header as HTTP_COMPANY? > > e.g is Rack smart enough not to prefix HTTP_COMPANY with HTTTP_ again? > > Kind regards, > Arne > > -- > > --- > You received this message because you are subscribed to the Google Groups > "Rack Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to rack-devel+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > --=20 ---=20 You received this message because you are subscribed to the Google Groups "= Rack Development" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-devel+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. --001a114427e4d897ea053f9b2747 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Arne,

When the client sends a reques= t which looks like this:

GET / HTTP/1.1
= Host: example.com
Company: Acm= e

The server you're using will always create t= he following environment:

{
=C2=A0 '= HTTP_COMPANY' =3D> 'Acme',
=C2=A0 'HTTP_HOST&#= 39; =3D> 'example.com',
=
=C2=A0 =E2=80=A6
}

If the client se= nds a request which looks like this:

GET / HT= TP/1.1
=
Http-Company: Acme

Then the environment= will look like this:

{
=C2=A0 '= ;HTTP_HTTP_COMPANY' =3D> 'Acme',
=C2=A0 'HTTP_= HOST' =3D> 'example.com',=
=C2=A0 =E2=80=A6
}.

So = yes: If you're using Rack directly, you will need to use HTTP_COMPANY o= n the server-side, and that will correspond to the "Company" head= er sent from the client.


// Magnus Holm

On Mon, Oct 24, 2016 at 10:16 AM, Olivar Pla= ys <arne.de.herdt@gmail.com> wrote:
Hello,

I have a small question abo= ut the behaviour of Rack when it comes to headers send by clients.
Are t= hese always prefixed with HTTP_ ? Or do I need to tell my clients to explic= itly send them as HTTP_ ?

Example, I'm checking on every request= in my Rails application whether the HTTP_COMPANY header is present, and ha= s the correct value.
But I've been running into issues with detectin= g them.
Right now I have the client app send the headers as COMPANY, and= my Rails app checks as HTTP_COMPANY.
Is this the intended behaviour, or= will this go wrong again when the client suddenly submits the header as HT= TP_COMPANY?

e.g is Rack smart enough not to prefix HTTP_COMPANY with= HTTTP_ again?

Kind regards,
Arne

--

---
You received this message because you are subscribed to the Google Groups &= quot;Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-devel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups &= quot;Rack Development" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to rack-dev= el+unsubscribe@googlegroups.com.
For more options, visit http= s://groups.google.com/d/optout.
--001a114427e4d897ea053f9b2747--