search

brefphp / bref

Serverless PHP on AWS Lambda
https://bref.sh
MIT License
3.16k stars 365 forks source link

Small suggestion for documentation relating to cookie session driver #995

Open Mesuva opened 3 years ago

Mesuva commented 3 years ago

Quick story Today I hit an issue with one of my deployments where doing a post request with some JSON triggered a 502 bad gateway error. This error didn't appear in any logs.

This was odd, as the json body wasn't really that big, maybe 3-4 kilobytes at most. Submitting the same kind of data, but cut down a bit, resulted in a successful post with no errors thrown. I was scratching my head for some time, as I was no where near the 6MB post limits, or anything else of that nature. I started to think about that minimumCompressionSize value, for example.

Then I realised what the issue was - I'd forgotten that after this particular POST request I stored in the session the submitted data, to then review on screen, and be saved down in another step.

Then I recalled reading how bref by default uses cookies to store session data: https://bref.sh/docs/frameworks/laravel.html#how-it-works

So what I believe was happening is that I was easily hitting the limit for cookie data, and either the gateway or bref didn't like that. I've since changed over to the database cookie driver and everything is working great.

My suggestion therefore is: it might be useful to add a short note to this section in the doco about the session driver, that if you are planning to store anything but small pieces of data in your sessions, that the database or redis driver would be recommended due to the size limitations of cookies.

Keep up the great work

deleugpn commented 3 years ago

Should we document / recommend the DynamoDB session driver?

Mesuva commented 3 years ago

I think the specifics about different sessions drivers should still be referenced within the relevant Laravel doco, no point duplicating the same information.

My point was more that the Laravel-Bref package automatically changes the session driver to a cookie based one, and that then has limitations that aren't immediately obvious. In other words, it's not a direct replacement for a file based driver, there needs to be some consideration when configuring bref whether it's suitable with your use-case.

My thinking is the doco could have a comment emphasising this limitation, and that it's not an automatic consideration that always works - it might need swapping over because of the limitation.

Now that I've realised the limitations, I'm likely to not leave it as the cookie based driver unless I know I'm not going to use sessions to store anything by tiny pieces of data.

SalehHub commented 3 months ago

I spent hours debugging this issue only to find out that cookie as SESSION_DRIVER was causing the 502 errors.