Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Cookies #208

Open
ljmc2000 opened this issue Jun 2, 2019 · 3 comments
Open

[Feature Request] Cookies #208

ljmc2000 opened this issue Jun 2, 2019 · 3 comments

Comments

@ljmc2000
Copy link

ljmc2000 commented Jun 2, 2019

So I was messing around with the python FDK and I noticed that there's no inbuilt wrapper around cookies. This isn't a huge problem because python's http lib deals with them swimmingly, but that generates some fluff code. Would it be possible to add a way to set and access cookies in the same way as http headers (ctx.Cookies() and return response.Response(ctx,"returned data", headers={"header1":"foo"},cookies={"cookie1":"bar"}) perhaps?) I originally opened a similar issue on the python fdk, and I was recommended to open one here so that if such a feature were to become supported it would be on all languages, not just python.

I reckon a fair few people would be using cookies anyway. If python supports them so well, I can't see node or ruby being far behind. Would this be possible? Would it be worth your time?

@zootalures
Copy link
Member

Cookies can be fairly easily extracted from the cookie header in the HTTP gateway context

Originally we tried to strike a balance between a low level HTTP/event binding and a fully fledged HTTP SDK.

PRs are welcome here

@ljmc2000
Copy link
Author

ljmc2000 commented Jun 2, 2019

Parsing them isn't the issue. that can be achieve in two lines and one of them is an import. The problem is sending them to the user in the first place. A small problem to be sure, but a nasty one. Python has a builtin module called http (at least I think its builtin). this has a submodule called cookies and that submodule is how python developers deal with cookies to my knowledge. problem is this. when you run str(cookies) it generates a list of headers to send to the client. this works great in a cgi environment because you send headers directly in that case. problem is it generates a list of headers all with the same name. something like 'Set-Cookie: bar=foo\r\nSet-Cookie: foo=bar'. wheras your implementation would expect 'bar=foo,foo=bar' (or something to that effect). now this is the fault of python for making such a convenient module that no one has felt the need to write a better one (to my knowledge). also adapting the former to the latter is not rocket science. a for loop and str replace could solve the problem it two lines.

in short it's a pet peave not an deal breaker. it still annoy's me though.

enough about why I want the feature though. I might make a pull request. I do believe the philosophy of do it yourself if you want it done right (or at all). No promises though. And if I do it will specifically be for python, because you know, that's what I use.

@ljmc2000
Copy link
Author

ljmc2000 commented Jun 3, 2019

So after a mornings reading RFC6265 and stack overflow, I might have uncovered a genuine issue. You cannot set multiple cookies in a single set-cookie header. The way it's meant to be is "set-cookie: foo=bar,bar=foo,tra=la" with cookies sepperated by coma. However, google chrome does not seem to implement this spec. Having manually set the headers to this format using cgi-bin scripts and python http, only the first cookie on the list is accepted (if any of them are). from what I can tell the only way to set more than one cookie at once is to send multiple set-cookie headers. the problem is that only one of each header may be sent using the present way of doing things (to my knowledge, correct me if I'm wrong). for reference, currently the headers are stored as a dictionary (a map of one value to another) which cannot store duplicate keys (header is key, header content is value). not sure if cookies are the only time that you'd want to send two headers with the same name, but now you know.

still not a big issue. it can probably be worked around. bit worse than a pet peave now though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants