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.8 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED,DKIM_VALID,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.0 Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.161.183]) (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 20FB320229 for ; Mon, 24 Oct 2016 11:54:37 +0000 (UTC) Received: by mail-yw0-f183.google.com with SMTP id w3sf60036276ywg.0 for ; Mon, 24 Oct 2016 04:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20120806; h=sender:date:from:to:message-id:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=KdMYVe9Cs7oLwE7iayPqU+RuCKzXkoJw6cpAS7BgnrU=; b=t4XlTxdcSH98d2EQdWIFyb6phfKbcXeX036zmrJBuP4zrHQdzVVvz5W3VFdp8OR5aD 1ANziD4rcA0/T6W5YEWhHPFXCvaM5q+IDTjIi+ywfHlyAqdQgYCBOsV5DnEmT0uEh9zQ 7gXRHxE5p/PRW+rk9CymOrJUQSNUCL9lgnULTGfMgCScOOojdpQUTTGCBagddoFrZu0+ NfCOjEbsQwBV1h3HHR4KVXrrtfn3fN1BT7Q3QesuvaKX09+obQiYL5xRg6MtQ6LF7vHT PH2RiEQG7ZFDzkz+3gdpMLVQFXbl0QiT0L6UVNa4Tafk699Uw6ZoLbZw/HpScS8xcogp FXgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=sender:x-gm-message-state:date:from:to:message-id:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=KdMYVe9Cs7oLwE7iayPqU+RuCKzXkoJw6cpAS7BgnrU=; b=MnkzwSyeq5WP6F8ZmqPUeZSvchsc/iLeJmcsepwMTibDpxd4ccY7SbpjFG5Cv7AZBr 9KLpiPtbr10b2g9O4trQ4nTxb6dom232h/Hz8ppk4uZ6rBX2Qb/qYNpD/y53jMIah18U qAMEXkUWom8+0apgNj3LWuRoDM4JbSQUETbWv3mnCZdrBEiEh4FxICu1aSxb5B04eiVJ XTy/333bE7LZ8MwsxWO0F+33L4iuBoY15rRpr7hQO4ncsvaWIw8PfU26oXMF3cHK2Sw8 buKF+ARVboRVaaIZILv4DQiMUpf+gsQeBUVzCoaUUP5ucuFo2dN40/vmF84u+JKWN/Mw JeZw== Sender: rack-devel@googlegroups.com X-Gm-Message-State: ABUngvdIJvZL51yAqWdBZ5HX3SyI+EH0JCRCjphKP43nD5ZHboz+JZb/YnMGYMjE8gfGog== X-Received: by 10.36.116.208 with SMTP id o199mr40918itc.6.1477310076222; Mon, 24 Oct 2016 04:54:36 -0700 (PDT) X-BeenThere: rack-devel@googlegroups.com Received: by 10.107.150.4 with SMTP id y4ls4076090iod.48.gmail; Mon, 24 Oct 2016 04:54:34 -0700 (PDT) X-Received: by 10.107.142.200 with SMTP id q191mr10863541iod.46.1477310074069; Mon, 24 Oct 2016 04:54:34 -0700 (PDT) Received: by 10.202.197.12 with SMTP id v12msoif; Mon, 24 Oct 2016 01:16:31 -0700 (PDT) X-Received: by 10.36.124.151 with SMTP id a145mr28402itd.2.1477296990916; Mon, 24 Oct 2016 01:16:30 -0700 (PDT) Date: Mon, 24 Oct 2016 01:16:30 -0700 (PDT) From: Olivar Plays To: Rack Development Message-Id: <6c68f46f-fdc5-4cd3-b36c-9b2c6bf3e03e@googlegroups.com> Subject: HTTP_ Headers from clients MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_375_985726061.1477296990208" X-Original-Sender: arne.de.herdt@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: , ------=_Part_375_985726061.1477296990208 Content-Type: multipart/alternative; boundary="----=_Part_376_539949548.1477296990208" ------=_Part_376_539949548.1477296990208 Content-Type: text/plain; charset=UTF-8 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 the 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. ------=_Part_376_539949548.1477296990208 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I have a small question about the behaviour = of Rack when it comes to headers send by clients.
Are these always prefi= xed 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 appl= ication whether the HTTP_COMPANY header is present, and has the correct val= ue.
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 che= cks as HTTP_COMPANY.
Is this the intended behaviour, or will this go wro= ng 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 &= 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.
------=_Part_376_539949548.1477296990208-- ------=_Part_375_985726061.1477296990208--