Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-08-18:

[15:20] <nrstott> in JSGI how should you set multiple Set-Cookie lines? headers is an object so I don't see how this is possible
[15:21] <WesMac> Set-Cookie, SEt-Cookie, sEt-Cookie, seT-Cookie?
[15:21] <nrstott> ugh
[15:22] <nrstott> that sounds awful
[15:22] <nrstott> is there not a better way? if not this seems like real weakness of the spec
[15:22] <WesMac> There might be a better way. I brought up that hole on the NG awhile back -- the case sensitivity part in particular -- and the feedback I got was along the lines of "that will never happen"
[15:23] <WesMac> You might be able to do something else ugly, like
[15:23] <WesMac> headers["Set-Cookie"] = "this\nSet-Cookie: that"
[15:23] <dmachi> you can always append to the existing one without having to create a new line
[15:23] <WesMac> But I don't know of a better solution. (Doesn't mean there isn't one, though)
[15:23] <WesMac> dmachi: does the cookie spec allow setting more than one cookie in a header?
[15:24] <WesMac> it's been a long bloody time since I've looked
[15:24] <WesMac> (I know locally I just generate as many as I need)
[15:24] <dmachi> yeah, i can't remember either, i would have thought it wouldnt' care, but i'm not sure of the behavior
[15:24] <dmachi> might be doable as an array?
[15:25] <WesMac> would require a tweak of the spec, but not a bad idea
[15:25] <nrstott> dmachi, how do you append to existing one?
[15:25] <WesMac> if (typeof(header[el]) == "array") output(header[el].join(headerName + ": ")
[15:25] <dmachi> WesMac: yah.
[15:26] <nrstott> the spec should defintiely allow an array for the Set-Cookie header imo. anything else is just ugly
[15:26] <dmachi> nrstott: well you could just add and the last one would probably take precendence if i had to guess, but otherwise i suppose you'd have to pull it out of that index element.
[15:27] <nrstott> wikipedia makes it sound like you can declare multiple cookies on one line querystring style
[15:27] <nrstott> http://en.wikipedia.org/wiki/HTTP_cookie
[15:27] <dmachi> WesMac: seems like it really should be an object so you just set the cookies by property, which there'd never be a duplicate of.
[15:27] <nrstott> but this is clearly not the case accoding to my test with chrome ;0
[15:29] <WesMac> dmachi: But that's just the problem - unless my memory is wrong (40% chance) you need separate cookie headers for separate cookies in order to keep the ecosystem (browsers, proxies) happy
[15:29] <WesMac> But, big caveat, I have not studied the issue in several years
[15:29] <WesMac> One thing I remember, though, is that there's two slightly different cookie specs out there
[15:29] <WesMac> one is deprecated, circa netscape 3, but comes up a lot in searches. It might be an RFC.
[15:29] <dmachi> i'm not sure thats right, it all ends up as one string in the browser as i recall and its a slightly odd but pretty easy format
[15:30] <WesMac> dmachi: run some tests, prove us wrong! :)
[15:30] <WesMac> nrstott: your other option, of course, is to set the cookie with javascript in the document <head/> *ugh too*
[15:30] <dmachi> i wrote a little thing so i could pass long gets on IE back and forth by adding some of the payload to cookies
[15:31] <nrstott> WesMac, this is clealry just a weakness of the spec
[15:31] <nrstott> i can hack around it with Set-Cookie and set-Cookie for now
[15:31] <nrstott> but that's so ugly
[15:31] <dmachi> and i know thats at least how the browser ends up representing it. so i'm not sure exactly what happens when you set multipel cookies, but i'd guess they just combine in the end.
[15:32] <dmachi> Servers may return a Set-Cookie response headers with any response.
[15:32] <dmachi> User agents should send Cookie request headers, subject to other
[15:32] <dmachi> rules detailed below, with every request.
[15:32] <dmachi> An origin server may include multiple Set-Cookie headers in a
[15:32] <dmachi> response. Note that an intervening gateway could fold multiple such
[15:32] <dmachi> headers into a single header.
[15:33] <dmachi> the last thing is essentially what the browser does.
[15:34] <dmachi> set-cookie = "Set-Cookie:" cookies
[15:34] <WesMac> dmachi: Try setting two cookies with one header
[15:34] <WesMac> dmachi: Then try it on a variety of browsers
[15:35] <WesMac> dmachi: I bet there's a reason that SOP is multiple headers
[15:35] <dmachi> well its definitely easier to read and perfectly acceptable to do multiple headers
[15:36] <dmachi> but my point is it seems like it should be headers["set-cookies"] = {"cookieName": props}, and then serializer can convert that into one or more actually header lines. That accomplishes things and allows one part of the stack to override or easily read the cookies before then.
[15:37] <dmachi> (as opposed to an array)
[15:37] <WesMac> dmachi: That's a good idea!
[15:40] <dmachi> :)
[16:43] <nrstott> dmachi, you want to write that into the wiki?
[16:43] <nrstott> cause that would be great
[16:43] <nrstott> id be happy to implement it in jsgi-node
[16:44] <dmachi> i was going to look and see if kris's version did it already first, but yeah i can add it to there
[16:44] <dmachi> can you be more specific on where, i've not edited that wiki before
[16:44] <WesMac> You .. shouldn't really change the spec without discussing the changes on the mailing list
[16:45] <dmachi> I'll just send an email there and let the discussion happen and the appropriate person can pudate?
[16:46] <WesMac> dmachi: You can update, provided the discussion goes in the right direction. Which I suspect it will.
[16:46] <WesMac> But remember, JSGI implementors aren't going to just keep re-reading the wiki, hoping to spot a spec change. That's incredibly hostile.
[16:50] <dmachi> yeah, of course
[16:50] <dmachi> i sent an email to cjs
[16:50] <nrstott> WesMac, the wiki is there to be changed. I wouldn't expect that to be considered hostile. It also keeps revisions.
[16:50] <nrstott> discussion would be good on the mailing list as well
[16:51] <dmachi> will be happy to change after some +1s
[16:51] <WesMac> nrstott: Right - but you can't just go changing the wiki without discussing it with the group. *that's* what I consider hostile.
[16:52] <nrstott> WesMac, I'm just saying it'd be ok to change wiki then post to mailng list and ask for opinions imo
[16:52] <nrstott> maybe even preferable ;0
[16:52] <nrstott> so that everyone can see what exactly is proposed
[16:52] <nrstott> either way, as long as it gets discusse
[16:52] <nrstott> discussed*
[16:52] <WesMac> nrstott: How is somebody implementing JSGI supposed to know that that's just a proposal?
[16:52] <nrstott> WesMac, nothing in JSGI 0.3 is ratified...
[16:52] <nrstott> its all just proposal
[16:53] <WesMac> Well, yes, but IMHO the wiki should indicate roughly what page everybody has agreed to be on
[16:53] <dmachi> thats true, but there is general agreement on parts and implementations. its easier to ask first i this case, if it were someting major i'd make a proposal page.
[16:53] <nrstott> fair enough
[16:53] <WesMac> otherwise, I could realistically implement anything I want, document it in the wiki and say I'm JSGI 0.3 compliant
[16:53] <nrstott> WesMac, isn't taht the current reality? :)
[16:54] <WesMac> It's not *quite* the reality - there has been a lot of group-thought and re-think of everything that's in there atm
[17:29] <kriszyp> dmachi: does your proposal serialize to multiple headers a single header with comma separated values? or something else...
[17:33] <dmachi> i don't propose how thats done, as far as I can tell the spec defines how to do that
[17:33] <dmachi> (http spec)
[17:35] <dmachi> they could be done as individual set-headers as what nrstott was trying to achieve from the same definition
[17:36] <nrstott> right, i ran into a situation today using jsgi-node where i needed to set 2 cookies in the smae response and i had to use Set-Cookie and set-Cookie headers to hack around it
[17:36] <nrstott> obviously not ideal
[17:43] <deanlandolt> nrstott: headers are lowercaqse
[17:44] <deanlandolt> multiple headers can be provided as an array
[17:44] <deanlandolt> (an array toString's down using join(",") as per the http spec so it's perfect)
[17:44] <nrstott> deanlandolt, not all browsers seem to be ok with that
[17:45] <nrstott> deanlandolt, specifically my wifes firefox on mac didn't seem to accomodate the multiple cookie values in 1 set-cookie header
[17:45] <deanlandolt> certainly not, which is why it's in the spec...so servers could respect that and provide multiple headers
[17:45] <nrstott> oh...
[17:45] <deanlandolt> which server are you using?
[17:45] <nrstott> node
[17:45] <deanlandolt> try the array trick...i thought jsgi-node respects that
[17:45] <nrstott> it may, ill check
[17:46] <dmachi> thats what we discussed above a bit, i think its fine to do that too, i just suggested the object because nrstott was asking how to get at a particular one, which would have to be done via lookup in the array rather than cookie name
[17:47] <deanlandolt> dmachi: sure, but that's where a middleware helper would come in handy
[17:47] <deanlandolt> i think jack's cookie stuff does something useful around htat
[17:49] <dmachi> sure, could be done in a number of places in the stack i'd guess
[17:51] <dmachi> i am going to write a test to see if everything since ie6 accepts a combined cookies on a single header. I'm skeptical that they don't as I don't recall having come across _that_ issue (of course ie6/7 have 2k max (actually i think something like 50 pairs max and 2k)) but i don't remember hitting the headers issue.
[17:52] <deanlandolt> but that's easy...don't combine them
[17:52] <deanlandolt> keep them in an array
[17:52] <deanlandolt> everything else that i'm aware of can be combined
[17:53] <dmachi> no i mean ultimately cookies in ie have that limiatation dropping the oldest pairs first. having separate set-cookie headers is of course fine with me. I am just curious and skeptical as to there are any modern browsers that don't accept that properly
[17:54] <dmachi> especially since the spec says that serivces in the middle may collapse multipel set-cookies down to one.
[17:55] <dmachi> so yes, an array is perfectly fine over an object, the object was only suggested to allow faster inspection / modification before it is serialized in the end.
[17:58] <dmachi> I guess the object is good from a practical perspective, though technically it is probably wrong since you can have (with spec undefined behavior) the same cookie name twice.
[17:59] <deanlandolt> actually it creates a whole nother interface that has to be respected, so it's a little burdensome from a practical perspective as well
[18:00] <dmachi> not sure i quite understand that, as the middleware can figure out what to do based on what it has (could still be a string or an array), but i'm certainly no expert in the details of the jsgi spec.
[18:16] <ashb> '< deanlandolt> everything else that i'm aware of can be combined' i think that was my expierment result too
[18:17] <ashb> dmachi: what is the practical outcome of same cooke name but fdiff value twice?
[18:19] <dmachi> i think it got either the first or the last in the string, but you couldn't read or set the other unless you looked at the cookie string itself and parsed it out.
[18:19] <dmachi> its been a couple years since i did that project
[18:20] <dmachi> ashb^
[18:25] <deanlandolt> still, what's the big deal with keeping set-cookie as an array? you can have a helper object to get by name if needed...it's not like there's a perf penalty
[18:25] <deanlandolt> i mean, you're looping over what, 3 or 4 items at most?
[18:42] <nrstott> deanlandolt, that's a good point
[18:44] <dmachi> true enough, fine with me

 

 

Logs by date :