Hvad er rækkefølgen i .nextElement() ?

Jeg er ret sikker paa at du har ret.

Proev evt. at udskrive headerNames.getClass().getName() - jeg har en staerk mistanke om at de headere gemmes i en form for Map - hvilket giver god mening for at kunne slaa op med header navn som key - men som ogsaa betyder at raekkefoelgen gaar tabt.

https://github.com/undertow-io/undertow/blob/master/servlet/src/main/java/io/undertow/servlet/spec/HttpServletRequestImpl.java

https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/HttpServerExchange.java

https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/util/HeaderMap.java

siger at JBoss Undertow bruger en speciel map.

Det er faktisk et interessant (laes: vanskeligt problem).

Et servlet filter bruger ogsaa de pre-parsede og gemte headere.

Det kan naturligvis goeres med en ServerSocket, accept, Socket, getInputStream, BufferedReader - men det integrerer jo ikke med en Java web app.

@ #2
"Proev evt. at udskrive headerNames.getClass().getName() "
Rerultatet er:
org.apache.tomcat.util.http.NamesEnumerator

@ #1
Se venligst min kommentar under @ #2, som retteligt burde være svar til #1.
Jeg mangler Elon Musks forslag til implementation om at kunne rette i et nyligt skrevet indklæg.

Ja - det fortæller jo ikke så meget - jeg havde troet at det havde været en intern klasse i en map klasse.

Men jeg tror stadig at problemet er at den parser headerne og gemmer dem i en map hvor man så henter dem ud sorteret efter hash kode eller lignenden og ikke efter raekkefoelge i input.

Men:

https://github.com/apache/tomcat/blob/main/java/org/apache/tomcat/util/http/MimeHeaders.java

siger at jeg tager fejl - det er bare et array.

Altså der er ingen tvivl om at Java EE / Jakarta EE standarden ikke garanterer at rækkefølgen ved den enumerering svarer til rækkefølgen i input.

Men for at afklare om Tomcat faktisk bevarer rækkefølgen kan du prøve at putte TCPMon mellem browser og Tomcat. Den viser de raa request og response.

https://ws.apache.org/tcpmon/

Min hjemmeside ligger på et web-hotel hos Levonline.com, så jeg tror ikke, at det er muligt at benytte TCPMon. Det fremgår heller ikke af TCPMon's dokumentation, hvordan jeg i givet fald skulle installere TCPMon.

Derudover,... selvom jeg kunne installere TCPMon, så ville det ikke hjælpe særlig meget. Jo, jeg kunne få bekræftet, at Java rokerer om på data, men jeg kan jo ikke bruge den viden til noget. Jeg har brug for at vide, hvordan jeg - ved brug af Java -
kan læse de korrekte data i den korrekte rækkefølge.

Men jeg har prøvet noget andet:
Jeg har prøvet at kalde min browser.jsp application fra forskellige browsere, og rækkefølgen er forskellig for forskellige browsere.

Jeg ved ikke helt, hvad jeg kan udlede af det - om noget som helst.

Hvis rækkefølgen var den samme for alle browsere, så kunne det indikere, at Java lavede en form for sortering.
Men da Chrome, Opera og Firefox ikke returnerer de samme informationer (læs headerNames) så kan der måske stadigvæk ske en form for sortering, der blot  er uigennemskuelig med det lille datagrundlag (Opera, Firefox, og Chrome), jeg har.

Opera og Firefox leverer de samme headerNames i den samme rækkefølge, men det er sikkert fordi, Opera og Firefox benytter den samme engine.

Jeg har nu prøvet forskellige hjemmesider, der angiveligt påstår at vise mig den korrekte rækkefølge.
Desværre er de ikke enige om, hvad den korrekte rækkefølge er, suk...

Du kan sagtens bruge TCPMon selvom det er et web hotel.

browser på din PC---TCPMon på din PC---web app på web hotel

TCPMon er bare en jar fil som du kører. Så angiver du at port 12345 skal forwardes til www.noget.dk port 80 og saa lader du din browser connecte til http://localhost:12345/whatever.

Primitivt værktøj men du kan se hvad der sker.

Det er lettere sagt en gjort.

Det meste af TCPMon's side er mest døde links.
Men det er lykkedes mig dog at finde en tcpmon-1.0.jar
Jeg har også checket med MD5, at filen ikke er kompromiteret.
Men, når jeg forsøger at køre den med:
"java -jar tcpmon-1.0.jar"
får jeg følgende svar
"no main manifest attribute, in tcpmon-1.0.jar"

Når jeg søger på internettet, får jeg løsningsforslag, der bygger på enten Maven eller Gradle,... jeg bruger ingen af delene.

Jeg *kunne* jo bare installere Maven, men er det ikke at gå over åen efter vand?

Jeg hentede den for en 15-20 år siden.

:-)

https://archive.apache.org/dist/ws/tcpmon/1.0/ og tag bin versionen

start med:

java -cp tcpmon-1.0.jar org.apache.ws.commons.tcpmon.TCPMon

synes at virke.

Gå til admin tab og angiv local port der skal lyttes på og hvad der skal connectes til.

Det virker, det virker ! (næsten)
Nu kan jeg se, hvad min browser sender til serveren.
Og nej, det er ikke den samme rækkefølge som .nextElement()
Så langt så godt...

Når jeg skriver "næsten", så er det fordi jeg starter ud med HTTP med target port 80 og listener port 8080, men den egentlige kommunikation foregår jo med HTTPS.
Jeg har forsøgt med target port 443, men så får jeg fejl 400 Bad Request fra Cloudflare, som jeg benytter som frontend. Og den fejlmeddelelse giver jo fint mening.

Som det er nu, skal jeg dele min test op i to tests:
1) sende på port 80 via TCPMon for at se, hvad browseren initielt sender.
2) kalde browser.jsp udenom TCPMon for at se, hvad browser.jsp returnerer.

Jeg ville jo egentlig gerne nå så langt, at jeg - i TCPMon - kan se den fulde kommunikation fra jeg trykker "enter" på min browser og til jeg kan se svaret fra browser.jsp applikationen på web-serveren.

Umiddelbart kan man jo mene, at det er ligegyldigt, når jeg allerede har påvist, at jeg ikke kan benytte .nextElement().
Og ved nærmene eftertanke vil jeg sikkert heller ikke få noget brugbart ud af det, da HTTPS jo er krypteret.

Jeg synes, at jeg har fårt svar på mit oprindelige spørgsmål, selvom svaret ikke er det, jeg havde håbet på.
Jeg vil starte en ny tråd op med hvordan man - om muligt - så får den rigtige rækkefølge.

TCPMon er fra før man begyndte at bruge HTTPS til alt.

Jeg tror ikke at det er nemt fordi at servlet containeren processer headers inden ens kode udføres.

Men jeg vil tænke lidt over det.