feat: set error for incorrect usage of Set-Cookie response header

[TheGB0077]

Follow up to my previous commit in #2111.

Now that it []string is a valid cookie type, the framework should validate that only string types can be valid inputs.

[encore-cla[bot]]

All committers have signed the CLA.

[eandre]

Hey, thanks for the PR. I'm not sure this is actually needed. It seems to me that it's perfectly fine to encode integers as header values in the general case, and I'm not sure that we really need special handling for this particular header. There are a lot of headers out there that have specific formats, and not all of them make sense as integers, but this doesn't seem to be a particularly likely issue to pop up in practice?

[TheGB0077]

Hey, thanks for the PR. I'm not sure this is actually needed. It seems to me that it's perfectly fine to encode integers as header values in the general case, and I'm not sure that we really need special handling for this particular header. There are a lot of headers out there that have specific formats, and not all of them make sense as integers, but this doesn't seem to be a particularly likely issue to pop up in practice?

Hey there Andre! As far as I understand, the data representation should be a string in order to be decoded into the correct data layout of a cookie, containing data such as Name, Value, Expiration, Same site policy, etc.

So the setup would be:

	cookie := http.Cookie{
		Name:     "access_token_cookie",
		Value:    tk.AccessToken,
		Path:     "/",
		Expires:  time.Now().Add(accessTokenDuration),
		SameSite: http.SameSiteLaxMode,
		HttpOnly: true,
		Secure:   true,
	}
	
	refresh_cookie := http.Cookie{
		Name:     "refresh_token_cookie",
		Value:    tk.RefreshToken,
		Path:     "/",
		Expires:  time.Now().Add(refreshTokenDuration),
		SameSite: http.SameSiteLaxMode,
		HttpOnly: true,
		Secure:   true,
	}
	
	AuthResponse{
		SetCookie: []string{cookie.String(), refresh_cookie.String()}
	}

Then, in a scenario where the Cookies are set as arbitrary integer values, how does encore handle the remaining fields besides Value?

(In particular Name which needs a well-defined accessor to be used in the backend as a parameter cookie:"<cookie-name>"

[eandre]

I mean I agree. But my point is that lots of headers have specific formats that they need to adhere to. Should we do the same for all of them? Where do we draw the line? Enforcing that this particular header must be a string doesn't prevent you from encoding the string incorrectly. Is this motivated by a specific bug or issue? I kind of struggle to see how this would happen in practice.

[TheGB0077]

I mean I agree. But my point is that lots of headers have specific formats that they need to adhere to. Should we do the same for all of them? Where do we draw the line? Enforcing that this particular header must be a string doesn't prevent you from encoding the string incorrectly. Is this motivated by a specific bug or issue? I kind of struggle to see how this would happen in practice.

Yeah, that's something that could indeed be a slippery slope, although from my POV, this warning would be more of a “compiler enforcement/hint” of best practices.

While before there was a strict only string check in place, I would tend to believe the more straightforward change would be to allow string or []string in order to still have some level of feedback during dev time. Of course, it's not critical, and really I can only point out potential LLM hallucinations in agentic workflows where this check could prove itself useful.

[TheGB0077]

Although, I suppose that if we were to enforce things more properly then using the http.Cookie or even the Cookiejar interface would be more correct

[eandre]

On balance I don't really see a compelling need to enforce this when the use case you mentioned ("avoiding LLM hallucinations") is hypothetical. I don't believe LLMs are likely to try to encode a cookie header as an integer, so closing this for now.