Path: csiph.com!weretis.net!feeder4.news.weretis.net!feeder1.news.weretis.net!news.solani.org!.POSTED!not-for-mail From: Thomas 'PointedEars' Lahn Newsgroups: comp.lang.javascript Subject: Re: Difference between client and server side cookie Date: Mon, 14 Mar 2016 01:54:04 +0100 Organization: PointedEars Software (PES) Lines: 104 Message-ID: <4382627.JkLruRRTPY@PointedEars.de> References: <87wpp67j6w.fsf@bsb.me.uk> <2325956.yKQUHyJ2TD@PointedEars.de> <87y49m54i6.fsf@bsb.me.uk> Reply-To: Thomas 'PointedEars' Lahn Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Trace: solani.org 1457916845 4012 eJwFwQcBACAMAzBL+zA57NS/BBLX4Ohj4WEOhwZptjgsE3JLTMfqFs8Stdib84Q2MgvLig8M0hD/ (14 Mar 2016 00:54:05 GMT) X-Complaints-To: abuse@news.solani.org NNTP-Posting-Date: Mon, 14 Mar 2016 00:54:05 +0000 (UTC) User-Agent: KNode/4.14.2 X-User-ID: eJwNyEkBwDAIBEBLhBs5hLD+JbTzHBM/PqFurgaDPNsVVfYBvc5+aGoEC/Ep3i3pPmOom7s+dm9QiVP+haQPbbAV9A== Cancel-Lock: sha1:Zm0cOpoi4v3Q7reEYLMX1QwMblM= X-NNTP-Posting-Host: eJwVxMkRgDAMA8CW4ktB5RgF919Chn1sBQzaiULW1CwPayfetc1ZJsURz5+U8YDTkAP5NcG8Cw8Qqg== Xref: csiph.com comp.lang.javascript:29971 Ben Bacarisse wrote: > Thomas 'PointedEars' Lahn writes: >> Ben Bacarisse wrote: >>> He's saying that there are sometimes cookies "on the server" -- >>> specifically they are sent there every time a client makes a request for >>> which a cookie is relevant. >> >> In fact, only cookie *names* and *values* are sent with every HTTP >> request that applies to their “domain”, “path” and “secure” attributes, >> unless they have expired (as specified by the “expires” attribute in a >> former HTTP response header “Set-Cookie” field value or in the value >> assigned to the document.cookie property). >> >>> Where are they while the server is using them if not "on the server"? >> >> Still stored on the client machine. > > And on the server while the server is processing the request. Nonsense. >> Cookies are data (stored in local files) only whose *names* and *values* >> are incorporated into a HTTP request header “Cookie” field value. > > But it is not a cookie only when in some client's store. Yes, it is. > The RFC (6265) defines a cookie as a name/value pair No, it does not: | 4.2.2. Semantics | | Each cookie-pair represents a cookie stored by the user agent. The ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | cookie-pair contains the cookie-name and cookie-value the user agent | received in the Set-Cookie header. | | Notice that the cookie attributes are not returned. […] > and it is still a cookie as that name/value pair is sent over the wire. No, it is not. A representation is _not_ the real thing. Like in ECMAScript where a string representation of an object is _not_ the object itself. > This is clear from the language the RFC uses: Your interpretation is not supported by that RFC; in fact, it is refuted by that. > "The semantics of individual cookies in the Cookie header are not > defined" > > "if the Cookie header contains two cookies with the same name" > > "if the user agent fails to return one or more cookies in the Cookie > header" By the RFCs own definition, the Cookie header (field) value is _not_ a cookie, too. It is a comma-separated list of cookie name-value pairs (“cookie-pairs”) sent by the client to the server. The RFC is contradicting itself here partially, due to imprecise wording. > "The active network attacker can intercept these cookies" > > "the user agent will include that cookie in HTTP requests" Fallacy: Straw man. The first phrase is referring to the information sent from the server to the client, not vice-versa, as the value of each “Set-Cookie” *response* header field does constitute a cookie on the client *if it is stored there*. As for the second phrase, see above. > and so on. Fallacy: Hasty generalization. > It is perfectly reasonable to talk of the cookie in transit, > in the header and arriving (to be stored however temporarily) on the > server. No, it is not. >>> It's a small point, but it's not wrong. >> >> Yes, it is. >> >> > > The RFC is definitive. If this Wikipedia article contradicts it, > Wikipedia needs to be corrected. You are, in the best case, misinterpreting the RFC (which is only a *Proposed* Standard now, so in no way definitive; see RFC 2026, §4.4.1) completely. In the worst case, you are quoting from it selectively deliberately in order to support your opinion. Fallacy: Cherry picking. -- PointedEars FAQ: | SVN: Twitter: @PointedEars2 | ES Matrix: Please do not cc me. / Bitte keine Kopien per E-Mail.