[JSP/JAVA] Redirecting POST data

[Verwijderd]

Ik heb het volgende probleem.

Ik ben bezig met een webapplicatie die gebruikt maakt van jsp.

Nu gebruik ik 1 jsp pagina van waaruit alles gestuurd wordt.
Bijv.
De gebruiker vult een form op een bepaalde pagina in. Het form wordt gepost naar die ene jsp pagina die er allemaal checks op los, laat, database access doet etc. etc. En op het einde wordt de gebruiker geredirect naar een andere pagina.

Als ik de pagina redirect moet er ook af en toe data meegestuurd worden. Nu doe ik dat via sendRedirect(url) en dan de data die ik mee wil hebben plak ik gewoon achter de url (oftewel het wordt een GET post).

Nu is het probleem alleen dat er op een bepaalde pagina zoveel data ingevoerd wordt dat die boven de limiet komt die meegestuurd mag worden en dan krijg ik een 414 Error message (wat ook klopt).

Nu wil ik dus in plaats van de data erachter plakken een POST response sturen. Alleen ik heb geen flauw idee hoe ik dat mbv java/jsp doe.

Heeft er hier mischien iemand een idee...

[ACM]

Kan je dat niet beter in een session stoppen?

[Verwijderd]

Mischien wel, maar ik ben in het begin uitgegaan van een applicatie waar de data niet in grote hoeveelheden verstuurd zou hoeven te worden en dan is het opstellen van requesturls wel lekker makkelijk.

En als ik nu voor dit probleem over ga op sessies moet ik ook een aantal andere pagina's gaan herschrijven die automatisch de request/post params uitlezen checken etc.

Alles is opgebouwd rond forms die data posten en ik heb al een hekel aan forms en niet zo veel zin om die allemaal aan te gaan passen.

Maar ht was mischien een slimmere keuze geweest als ik dat in het begin gedaan had.

[Onno]

Op dinsdag 11 december 2001 10:18 schreef Sosume het volgende:
Heeft er hier mischien iemand een idee...

Ja hoor: het kan niet. En dat is geen beperking van JSP, maar HTTP biedt die mogelijkheid gewoon niet. Dus je zult inderdaad iets als sessions moeten gaan gebruiken. Of natuurlijk alles in cookies stoppen, dan hoef je server-side niks te onthouden, en kun je toch data aan je client meegeven die op de volgende pagina weer naar de server gestuurd wordt.

[Verwijderd]

Als je echt 0 zin hebt om over te stappen op sessies kun je ook nog voor dit speciale geval de data ergens neerzetten (file,db) en dan in de url een indicatie meegeven van waar de data te vinden is (filename, id)

[Verwijderd]

Is het niet mogelijk om zelf wat met http headers te klooien.

Als ik zelf de headers set.
Bijv:
contentType op application/x-www-form-urlencoded
en dan als een stream de data die ik wil hebben naar buiten stuur moet ik toch een post submit kunnen simuleren.

grumble... stom http protocol.

[Onno]

Op dinsdag 11 december 2001 12:50 schreef Sosume het volgende:
moet ik toch een post submit kunnen simuleren.

Nee. En dat is geen stomheid van HTTP, dat is gewoon niet iets wat je uberhaupt moet willen doen. Voor zulk soort dingen bestaan cookies.

[GiLuX]

volgens mij probeer jij te bereiken waar struts al precies de oplossing voor bied.
http://jakarta.apache.org/struts/index.html

[Verwijderd]

Ik weet niet of dit iets is wat je uberhaupt niet zou willen?

Ik wil gewoon dat vanuit 1 centrale pagina via een achterliggende servlet/class bijvoorbeeld alle database access geregeld wordt.

bijv.
1ste page stuurt met GET id=1 naar de centrale pagina, die gaat lekker vroeten in een database, en krijgt een hoop data terug. Die data wordt doorgestuurd naar pagina 3 als GET (appended to url).

Zo doe ik het op dit moment, is toch niet zo raar. Nu is alleen de data te groot om te appenden achter de url, dus wil ik het via een post query sturen, maar dat blijkt nu niet te kunnen.

Dus..... dan moet ik maar iets anders verzinnen. Is alleen jammer want alle pagina's zijn wel zo opgebouwd.

Hmm... struts.. es even wat dieper naar kijken.

[Onno]

Op dinsdag 11 december 2001 13:24 schreef Sosume het volgende:
Ik wil gewoon [...]

Ik snap prima wat je wilt, maar de manier waarop is helemaal fout. Als je data aan clients wilt meegeven zodat die bij volgende requests naar je webserver weer meegegeven wordt, moet je cookies gebruiken. Of nog mooier: die data helemaal niet naar de client sturen, maar sessions gebruiken.

Zo doe ik het op dit moment, is toch niet zo raar.

Eigenlijk wel. Je kunt beter eens op zoek gaan naar een manier om je scripts te laten werken, *zonder* dat er allemaal data naar clients moet, om vervolgens weer direct naar je server teruggestuurd te worden.

[Verwijderd]

Het gaat er mij niet om dat ik de state waarin de gebruiker zich bevindt wil bewaren. Als ik dat zou willen zou ik het inderdaad wel via sessies of cookies doen.

Wat ik wil is 1 centrale plek waar al het proces/controle gebeuren plaatsvindt en de rest krijgt zijn data van die centrale plek. Ik wil niet dat pagina's die alleen maar dienen om wat data weer te geven of te inputten ook nog allemaal database access moeten doen en checks op die invoer moeten uitvoeren.

Ik wil dat die pagina's doen waarvoor ik ze gemaakt heb. Data laten zien, en data kunnen invoeren niets meer/niets minder.

Nog maar eens een keertje een voorbeeldje

pagina 1. Een form pagina met 13 velden waar veel ingevuld kan worden oa. usernames en filenames. Deze gegevens kunnen tijdelijk opgeslagen worden of echt verstuurd worden.
pagina 2. Centralepagina die checks uitvoert en bepaald wat de volgende pagina wordt.
pagina 3. Een overzichtpagina waar tijdelijk opgeslagen forms staan.

Gebruiker vult het form in en slaat de gegevens tijdelijk op. Het form wordt gesubmit en naar pagina 2 gestuurd, die controleerd het form of usernames wel bestaan of files bestaan en meer van dat soort checks. Als het form ok is wordt het opgeslagen in de database. En wordt de gebruiker doorgestuurd naar pagina 3 waar een overzichtje staat met alle tijdelijk opgeslagen forms.
Daar klikt de gebruiker weer op 1 van de links, weer naar pagina 2 die de gegevens ophaalt en naar pagina 1 stuurt om ze weer weer te geven zodat de gebruiker ze weer kan wijzigen.

Omdat ik dus niet op alle pagina's grote/complexe checks en database access wil, deze wil ik centraal geregeld hebben. Maak ik van deze structuur gebruik.

Er moet dus wel hele tijd data tussen de clients heen en weer worden gestuurd.

Gebruik van cookies is niet mogelijk, werk hier op een bedrijf waar de webbrowsers voor 95% draaien op sun solaris 2.6 en waar de IT afdeling cookies uitgezet heeft.

Gebruik van sessies en sessievariabelen is wel mogelijk.. alleen om alles om te zetten naar sessies heb ik niet zo veel zin in.

[Onno]

Nog een keertje dan: wat je nu allemaal zegt begreep ik net ook al wel. Maar dat verandert niks aan de situatie of de oplossing. Als jij data wilt teruggeven in een redirect, moet dat via cookies. (of via de url, maar dat is geen optie vertelde je eerder al) Een andere mogelijkheid is er niet.

Omdat ik dus niet op alle pagina's grote/complexe checks en database access wil, deze wil ik centraal geregeld hebben. Maak ik van deze structuur gebruik.

Ik denk dat je beter kunt gaan nadenken over een andere opzet, want dit blijkt dus niet alleen niet te werken nu de hoeveelheid data te groot is, maar het is ook een compleet verkeerd ontwerp als je 't mij vraagt.

Waarom zorg je er server-side niet gewoon voor dat na A B, C of D uitgevoerd wordt, in plaats van na A een redirect naar B, C of D te sturen. Dan hoeft er helemaal geen data naar de client, en voorkom je bovendien dat een client B, C of D kan aanroepen zonder dat A alles netjes gechecked heeft.

Gebruik van cookies is niet mogelijk, werk hier op een bedrijf waar de webbrowsers voor 95% draaien op sun solaris 2.6 en waar de IT afdeling cookies uitgezet heeft.

Gebruik van sessies en sessievariabelen is wel mogelijk..

Sessies gebruiken meestal ook een cookie.

[Verwijderd]

wat je nu allemaal zegt begreep ik net ook al wel.

volgens mij snap je toch nog niet helemaal wat ik bedoel

Als jij data wilt teruggeven in een redirect, moet dat via cookies. (of via de url, maar dat is geen optie vertelde je eerder al) Een andere mogelijkheid is er niet.

Ben ik ook (ondertussen) helemaal met je eens en voor dit ene probleem op die ene pagina (tussen de 45 andere) zal ik ook een andere oplossing moeten verzinnen, maar omdat het voor 1 probleem (wat buiten de specificaties van het project viel, maar iedereen wil altijd wat anders erbij) optreedt wil nog niet zeggen dat ik daarom heel mijn design aan moet passen.

maar het is ook een compleet verkeerd ontwerp als je 't mij vraagt.

Nou dat ben ik nog steeds niet met je eens. Het is een applicatie die het MVC (Model View Controller) model implementeerd. De jsp's zorgen voor de presentatie en de centrale controller jsp (met achterliggende servlets) zorgt voor het verwerken van de requests en de business logica.
En het werkt op deze manier ook perfect.... op die ene pagina na.
En ook al vervang ik alle lange url's met sessies dan blijft het ontwerp en de methode hetzelfde.

Waarom zorg je er server-side niet gewoon voor dat na A B, C of D uitgevoerd wordt, in plaats van na A een redirect naar B, C of D te sturen. Dan hoeft er helemaal geen data naar de client, en voorkom je bovendien dat een client B, C of D kan aanroepen zonder dat A alles netjes gechecked heeft.

Wat je hierboven beschrijft gebeurd ook. Alleen ik werk niet met sessies maar met data achter een url.
En alle processing gebeurt nu ook serverside. En er wordt ook geen nutteloze/overbodige data naar de client gestuurd. De redirects die gestuurd worden worden gestuurd vanuit de controller, en alleen maar vanuit de controller.

Een client kan zelf niks aanroepen, er is maar 1 pagina die ervoor kan zorgen dat je op een andere pagina uitkomt en dat is weer de controller pagina.

Sessies gebruiken meestal ook een cookie.

Kan best, maar de cookies staan hier in de browsers uitgeschakeld maar de sessies werken nog steeds goed.:)

[GiLuX]

omdat ik ook niet wil achter blijven met in herhaling vallen

volgens mij probeer jij te bereiken waar struts al precies de oplossing voor bied.
http://jakarta.apache.org/struts/index.html


wat struts is, is je frontend.

je definieert een forward,
als struts een link tegenkomt met de naam van je forward ( bv: <form action="logon"> ) gaatie automatisch de actie die daarbij hoort opzoeken en de class aanroepen die daar bij hoort,
bv een class die die input van je form controleert.

verder geef je aan waar die naar moet redirecten als het form netjes is ingevuld en wattie moet doen als het niet naar behoren is ingevuld.

heel handig en precies wat je zoekt.

hier een voorbeeld van struts-config.xml:

code:

<struts-config>
  <form-beans>
    <form-bean
    name="logonForm"
    type="org.apache.struts.example.LogonForm" />
  </form-beans> 
  <global-forwards
    type="org.apache.struts.action.ActionForward" />
    <forward name="logon" path="/logon.jsp"
       redirect="false" /> 
  </global-forwards>    
  <action-mappings>     
    <action
      path="/logon" 
      type="org.apache.struts.example.LogonAction"
      name="logonForm"
     scope="request"
     input="/logon.jsp"
     unknown="false"
    validate="true" />      
  </action-mappings>
</struts-config>

ik ben op dit moment iets dergelijks voor php te maken, althans, ik doe een poging.

[Verwijderd]

Ik heb gekeken naar het hele struts verhaal en het is zo ongeveer ook wat ik nu doe (alleen dan in een meer uitgebreidere mate). Als ik hier van te voren over gehoord had, had ik het mischien wel geimplementeerd.

Maar om nu 45 pagina's plus achterliggende servlets om te gaan lopen bouwen heb ik niet zo'n zin in.

Maar struts geeft wel weer wat ik nu ook gedaan heb (zonder het hele xml config gedeelte dan)