Hi,
Jetzt fehlt nur noch, dass der Browser per Header übertragen würde, ob (zum Zeitpunkt des Absenden des Requests) JS aktiviert ist oder nicht.
Wieso sollte diese Information serverseitig interessant sein?
Entweder du codest einen Fallback für Clients, die JavaScript nicht ausführen. Der lässt sich mit bewährten Techniken einbinden (Progressive Enhancement). Dann braucht der Server nicht zu wissen, ob der Client JavaScript ausführt. Entweder der Client lädt die Scripte herunter und führt sie aus, oder eben nicht.
Oder du bietest keinen Fallback, weil die Anwendung ohnehin JavaScript benötigt. Dann braucht der Server nicht zu wissen, ob der Client JavaScript ausführt, denn der Server setzt es stillschweigend voraus und es gibt auch keinen Alternative.
Ja, das ist natürlich alles völlig richtig.
Aber ich bezog mich (dem Kontext des Threads entsprechend) auf die Inhalte, die im HTML Code stecken, um bei (volumenmäßig) großen Inhalten ggf. anfangs nur einen Teil auszuliefern, sodass der User auf Wunsch jeweils den Rest per AJAX nachladen kann.
Für diesen Fall wäre mir zumindest keine (sinnvolle) Fallback-Lösung bekannt. Aber ich bin natürlich immer erpicht darauf, Neues zu lernen.
Obiger Fall macht imho insbesondere dann Sinn, wenn man zusätzlich noch Infos über die Art der Verbindung und die (Device) Viewportsize hätte (im Hinblick auf Mobile Devices mit kleinerem Display und ggf. "langsamen" GSM Verbindungen).
Außerdem könnte man sich so auch ggf. irgendwelche "umständlichen" Fallbackszenarien bezüglich der einzubindenden Images (Stichworte "Retina Displays" und "Image Size") ersparen.
Gruß Gunther