startSession() inside Diet templates creates the session key but silently fails to set it on response cookie

[ahmetsait]

I was trying to debug why every page access creates a new session key on my Redis instance and it turns out accessing SessionVar.value in a Diet template was automatically starting a session, except doing so in a Diet template results in client not receiving the session cookie for some reason. Calling startSession() or accessing SessionVar.value in a normal registered methods work as expected.

I think this is a pretty severe and hard to debug issue.

// dub.selections.json
{
	"fileVersion": 1,
	"versions": {
		"derelict-pq": "4.0.0",
		"derelict-util": "3.0.0-beta.2",
		"diet-ng": "1.8.3",
		"dpq2": "1.1.7",
		"eventcore": "0.9.35",
		"iopipe": "0.2.5",
		"jsoniopipe": {"path":"deps/jsoniopipe"},
		"mir-linux-kernel": "1.2.1",
		"money": "3.0.2",
		"openssl": "3.3.4",
		"openssl-static": "1.0.5+3.0.8",
		"stdx-allocator": "2.77.5",
		"taggedalgebraic": "0.11.23",
		"vibe-container": "1.4.1",
		"vibe-core": "2.9.6",
		"vibe-d": "0.10.1",
		"vibe-http": "1.2.1",
		"vibe-inet": "1.1.0",
		"vibe-serialization": "1.0.7",
		"vibe-stream": "1.1.1"
	}
}

[s-ludwig]

The problem is that Diet templates are rendered directly to the wire, so that the response header has already been written once you get to the processing of the template. So there really is no general fix for this, apart from manually rendering to a buffer and using HTTPServerResponse.writeBody afterwards, or just issuing the startSession before rendering the template.

On the other hand, it makes sense to think about whether there is a good possibility to generate a warning to make this easier to detect/debug.

[ahmetsait]

I see, that makes sense. Thanks for the quick response.

I think we can design some sort of locking mechanism for InetHeaderMap which will deny any modifications while locked and then HTTPServerResponse.bodyWriter would hold the lock until it's closed/destroyed.