Re: Lange GET parameters?
On Tue, 01 Jul 2003 11:37:10 +0200, John Bokma
<postmaster@castleamber.com> grabbed a keybord and dumped this in
nl.internet.www.server-side :
>
>> Het gaat in dit geval om het opvragen van gegevens, eigenlijk
>> verstuurt de servlet een sql query + wat extra info naar het php
>> script. Het php script voert deze sql query dan uit (dit kan niet
>> anders, php is de enigste taal die deze query kan uitvoeren) en geeft
>> vervolgens een pagina weer met info.
>
>TTTTTTTTTTTOOOOOOOOOOOOOOOOEEEEETTT!
>
>Je geeft een *wat* mee? EEN QUERY!!! Verdorie wat als iemand dat ziet en
>een DELETE FROM table doet? Of een DROP? Dus even jouw PHP aanroept!
>
Het zou natuurlijk kunnen dat PHP een DB user gebruikt die b.v. alleen
select rechten heeft...
Maar dit is zeker wel iets om aan te denken, voor de OP :)
Greetz,
PanMan.
--
Have you ever had a dream, that you were so sure it was real?
What if you were unable to wake from that dream?
How would you know the difference between the dream world,
and the real world? - The Matrix.
Re: Lange GET parameters?
On 01 Jul 2003 20:43:05 GMT, Frits van den Akker
<webnews@noordkromp.nl> wrote:
>Daniel Tryba <news_nl.internet.www.server-side@canopus.nl> wrote in
>news:bdsnm4$hqi$1@news.tue.nl:
>
>> Frits van den Akker <webnews@noordkromp.nl> wrote:
>>> <lange http GET aanroep>
>>>
>>> Volgens mij kan een GET maximaal 512 bytes bevatten.
>>
>> Dat is al lang niet meer zo weinig:
>> http://groups.google.com/groups?selm...%40news.tue.nl
>>
>> Volgens rfc 2616 is er helemaal geen maximale lengte.
>>
>
>Heb ik weer wat geleerd en is de oorspronkelijke vraag ook beantwoord:
>> Mijn parameters kunnen in enkele gevallen langer zijn dan 1000
>> characters, kan deze lengte problemen veroorzaken mbt. GET ?
>
Bedankt voor de handige link!
joop
Re: Lange GET parameters?
On Tue, 1 Jul 2003 21:05:32 +0200, uws <uws@xs4all.invalid> wrote:
>I <kiv2gv0nlcfsb2rm76bvm2v5geiub71cef@4ax.com>, Joop skrev:
>> Ideeen zijn welkom, maar een query doorgeven over GET lijkt mij de
>> beste oplossing, want servlet moet de query genereren, dat kan php
>> script niet en het c programma moet via php aangeroepen worden.
>
>Wat is dat dan voor iets dat Java wel kan en PHP niet? Het genereren van een
>string?
>
Als je de posts goed had gelezen had je het geweten, namelijk het
benaderen van een c programma waar alleen een php schil voor is.
joop
Re: Lange GET parameters?
On Tue, 1 Jul 2003 21:03:17 +0200, uws <uws@xs4all.invalid> wrote:
>I <5em2gvkgek7l11vostmsatgdh6flius2fi@4ax.com>, Joop skrev:
>> Is dat zo, bij sendRedirect() word er alleen maar.. ik kom er nu
>> achter dat een POST niet eens mogelijk is, want de browser moet de
>> post uitvoeren, niet de servlet, want de browser moet de door de php
>> genereerde pagina zien.
>
>Echt waar joh? Heb je enig idee waar je het over hebt? Ik snap er in ieder
>geval niets van.
>
Lijkt me best te snappen, als de servlet een post doet naar php krijg
de servlet de response en dus de php pagina, dit terwijl het eigenlijk
de client/browser moet zijn die de php pagina te zien krijgt.
joop
Re: Lange GET parameters?
On Tue, 1 Jul 2003 21:05:32 +0200, uws <uws@xs4all.invalid> wrote:
>I <kiv2gv0nlcfsb2rm76bvm2v5geiub71cef@4ax.com>, Joop skrev:
>> Ideeen zijn welkom, maar een query doorgeven over GET lijkt mij de
>> beste oplossing, want servlet moet de query genereren, dat kan php
>> script niet en het c programma moet via php aangeroepen worden.
>
>Wat is dat dan voor iets dat Java wel kan en PHP niet? Het genereren van een
>string?
>
>
Je bedoelt het anders :-) De servlet package bevat de logica die het
mogelijk maakt de query te maken, dit zijn enkele classes die op hun
buurt weer functies bevatten. Het zou dagen kosten om deze over te
zetten naar php en bovendien krijg je dan 2 versies van classes die
hetzelfde doen, dat lijkt me niet handig.
joop
Re: Lange GET parameters?
I <mc45gvcgkeqkdickpuh7ksvghconiq1bls@4ax.com>, Joop skrev:
> On Tue, 1 Jul 2003 21:05:32 +0200, uws <uws@xs4all.invalid> wrote:
>>I <kiv2gv0nlcfsb2rm76bvm2v5geiub71cef@4ax.com>, Joop skrev:
>>> Ideeen zijn welkom, maar een query doorgeven over GET lijkt mij de
>>> beste oplossing, want servlet moet de query genereren, dat kan php
>>> script niet en het c programma moet via php aangeroepen worden.
>>Wat is dat dan voor iets dat Java wel kan en PHP niet? Het genereren van een
>>string?
> Je bedoelt het anders :-) De servlet package bevat de logica die het
> mogelijk maakt de query te maken, dit zijn enkele classes die op hun
> buurt weer functies bevatten. Het zou dagen kosten om deze over te
> zetten naar php en bovendien krijg je dan 2 versies van classes die
> hetzelfde doen, dat lijkt me niet handig.
Ja, dat bedoelde ik. Ik dacht namelijk dat jij dacht dat het genereren van
de query (*niet* het executen ervan) niet zou kunnen in PHP. Maargoed, het
ging puur om de logic die nodig is voor de generatie van de query.
mvrgr, Wouter
--
uws mail uws@xs4all.nl
never lived never lived :: i'm in love -- black rebel motorcycle club
Re: Lange GET parameters?
Joop wrote:
> On Tue, 1 Jul 2003 21:03:17 +0200, uws <uws@xs4all.invalid> wrote:
>
>
>>I <5em2gvkgek7l11vostmsatgdh6flius2fi@4ax.com>, Joop skrev:
>>
>>>Is dat zo, bij sendRedirect() word er alleen maar.. ik kom er nu
>>>achter dat een POST niet eens mogelijk is, want de browser moet de
>>>post uitvoeren, niet de servlet, want de browser moet de door de php
>>>genereerde pagina zien.
>>
>>Echt waar joh? Heb je enig idee waar je het over hebt? Ik snap er in ieder
>>geval niets van.
>>
>
>
> Lijkt me best te snappen, als de servlet een post doet naar php krijg
> de servlet de response en dus de php pagina, dit terwijl het eigenlijk
> de client/browser moet zijn die de php pagina te zien krijgt.
Die pagina kan je toch doorgeven vanuit de servlet *naar* de browser?
Geen enkel probleem.
John
--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
website design tips: http://johnbokma.com/websitedesign/ (preliminary)
Re: Lange GET parameters?
Joop wrote:
> On Tue, 1 Jul 2003 21:05:32 +0200, uws <uws@xs4all.invalid> wrote:
>
>>I <kiv2gv0nlcfsb2rm76bvm2v5geiub71cef@4ax.com>, Joop skrev:
>>
>>>Ideeen zijn welkom, maar een query doorgeven over GET lijkt mij de
>>>beste oplossing, want servlet moet de query genereren, dat kan php
>>>script niet en het c programma moet via php aangeroepen worden.
>>
>>Wat is dat dan voor iets dat Java wel kan en PHP niet? Het genereren van een
>>string?
>
> Je bedoelt het anders :-) De servlet package bevat de logica die het
> mogelijk maakt de query te maken, dit zijn enkele classes die op hun
> buurt weer functies bevatten. Het zou dagen kosten om deze over te
> zetten naar php en bovendien krijg je dan 2 versies van classes die
> hetzelfde doen, dat lijkt me niet handig.
Stop die PHP shit in je servlet, daar hoort het IMHO ook.
John
--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
website design tips: http://johnbokma.com/websitedesign/ (preliminary)
Re: Lange GET parameters?
PanMan wrote:
> On Tue, 01 Jul 2003 11:37:10 +0200, John Bokma
> <postmaster@castleamber.com> grabbed a keybord and dumped this in
> nl.internet.www.server-side :
>
>>>Het gaat in dit geval om het opvragen van gegevens, eigenlijk
>>>verstuurt de servlet een sql query + wat extra info naar het php
>>>script. Het php script voert deze sql query dan uit (dit kan niet
>>>anders, php is de enigste taal die deze query kan uitvoeren) en geeft
>>>vervolgens een pagina weer met info.
>>
>>TTTTTTTTTTTOOOOOOOOOOOOOOOOEEEEETTT!
>>
>>Je geeft een *wat* mee? EEN QUERY!!! Verdorie wat als iemand dat ziet en
>>een DELETE FROM table doet? Of een DROP? Dus even jouw PHP aanroept!
>>
>
> Het zou natuurlijk kunnen dat PHP een DB user gebruikt die b.v. alleen
> select rechten heeft...
> Maar dit is zeker wel iets om aan te denken, voor de OP :)
Zelfs met *alleen* select rechten kan je nogal wat dingen lezen die
misschien niet gelezen mogen worden..
John
--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
website design tips: http://johnbokma.com/websitedesign/ (preliminary)
Re: Lange GET parameters?
Joop wrote:
> On Tue, 01 Jul 2003 11:37:10 +0200, John Bokma
> <postmaster@castleamber.com> wrote:
[snip]
> Maar dat gaat juist niet, de servlet kan de query niet uitvoeren, dat
*waarom* niet?
> kan alleen php. Het is namelijk zo dat er alleen een php schil bestaat
> voor een programma wat geschreven is in c wat niet multi threads
> ondersteund, via php benaderen is dus de enigste optie.
*waarom*? Pas op met threads en zo, ik kan met 2 browsers heel goed jouw
PHP programma vrijwel gelijktijdig aanroepen... als je c programma of je
database hiermee niet overweg kan is het einde echt zoek op deze
manier... Sterker, dan *moet* je misschien wel een servlet gebruiken of
file-locking vanuit PHP...
John
--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
website design tips: http://johnbokma.com/websitedesign/ (preliminary)
Re: Lange GET parameters?
Joop wrote:
> On Tue, 01 Jul 2003 12:56:21 +0200, John Bokma
> <postmaster@castleamber.com> wrote:
>
>
>>Joop wrote:
>>
>>
>>>On Tue, 01 Jul 2003 11:37:10 +0200, John Bokma
>>><postmaster@castleamber.com> wrote:
>>
>>[snip]
>>
>>
>>>Maar dat gaat juist niet, de servlet kan de query niet uitvoeren, dat
>>>kan alleen php. Het is namelijk zo dat er alleen een php schil bestaat
>>>voor een programma wat geschreven is in c wat niet multi threads
>>>ondersteund, via php benaderen is dus de enigste optie.
>>
>>??? Welke database is dat dan? Voor de meeste databases zijn er JDBC
>>drivers te vinden.
>
>
> De setup is redelijk ingewikkeld, het komt erop neer dat een servlet
> een webform genereert, een andere servlet handelt de POST af en maakt
> een zoek query. Deze query stuurt hij naar php script, php script
> roept c programma aan en geeft query door, c programma benadert een
> speciale postgresql module die de query uitvoert, het resultaat word
Waarom? Dit kan ook vanuit Java. Sterker, er is, weet ik zeker, een
postgesql driver voor Java... Wat is die module precies en wat doet dat
C programma? Vertel niet dat dat C programma er alleen maar is om de
query door te geven aan postgres en die weer terug te geven aan PHP??
> door het c programma omgezet naar een plaatje en bewaart op de
Ah, ok, ook iets wat je zo in Java kan doen hoor. Er is een prachtige
grafische library in Java. Ik heb keurige servlets gemaakt die allerlei
mooie grafiekjes maaken :-).
> hardeschijf, tot slot geef c programma path naar plaatje door aan php
file-locking? Wie ruimt dat bestand op... oei... ik vrees dat je hier op
gaat reageren dat altijd "plaatje.gif" wordt gebruikt en zie ik direct
je "threading" probleem, dat er overigens nog steeds is. Met twee
browsers op twee computers kan ik vast een keer je plaatje om zeep
helpen als het zo inelkaar zit als ik vrees...
> script, die het plaatje op een html pagina zet.
>
>
>>Overigens kan je die PHP schil ook zo in Java namaken. Zou niet weten
>>waarom niet. PHP kan echt niet meer dan Java. Zelfs als je een
>>c-programma wilt aanroepen kan dat vanuit Java.
>>
>>[snip moet ik even over nadenken, is al laat]
>
> Een php script runt bij mij als cgi (niet als .so module), dit
> betekent dat een php script als hij klaar is alle variabelen vrij
> maakt. Een servlet kan dit niet, die blijft constant draaien, er is
snap ik helemaal niks van, echt niet.
> wel een singlethread model, maar dat word afgeraden. Als 2 servlet
> requests op hetzelfde moment het c programma benaderen en het c
> programma houd hier geen rekening mee dan gaat het schijnbaar mis. Dat
Natuurlijk. Ook als twee bezoekers op hetzelfde moment je PHP aanroepen...
> is aan servlet kant wel op te lossen door bv mutex/sync, maar dan moet
> je zelf een hele schil gaan maken voor de c functies, dat kost aardig
> wat tijd.
Snap er echt niks van. Volgens mij *denk* je een probleem opgelost te
hebben dat er nog steeds *mega* is, nl het risico dat je plaatje
verminkt wordt. PHP helpt je daar echt niet vanaf. Het enige dat je zou
kunnen doen is in PHP een bestand maken dat je lock.file noemt, daar een
lock op gooien, C programma aanroepen, en lock.file unlocken als je het
plaatje terug hebt. (Let op! Niet als het C programma klaar is, want dan
heb je nog steeds een o-shit moment). Hmmm, ik zie hier nog wat problemen.
TIP: genereer het plaatje in je servlet, echt, dan voorkom je zo
vreselijk veel shit. Ik kan (tegen betaling cq. goodies :-) hier vast
bij helpen.
John
--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
website design tips: http://johnbokma.com/websitedesign/ (preliminary)
Re: Lange GET parameters?
Joop wrote:
> Dat is met een mutex/sync werken, maar dat is niet de bedoeling, er
Dat is wel de bedoeling. Als je C programma altijd het plaatje naar
hetzelfde bestand schrijft kom je daar gewoon niet onderuit, tenzij je
absoluut kan garanderen dat je bezoek *nooit* gelijktijdig komt en nooit
met meer dan een browservenster. Je programma kan al stuk gaan als je 2
keer het plaatje in 1 pagina opneemt... (Mooie test overigens, maar als
ie 100000 keer goed gaat, is dat nog geen garantie, *tenzij* je sync heb
toegepast).
> moet via de php schil gewerkt worden, ander moet ik zelf java schil
> maken en dat kost tijd.
Uitbesteden :-).
John
--
email: mail(at)johnbokma.com (or reply) home: http://johnbokma.com/
website design tips: http://johnbokma.com/websitedesign/ (preliminary)
Re: Lange GET parameters?
On Thu, 03 Jul 2003 02:44:31 +0200, John Bokma
<postmaster@castleamber.com> wrote:
>Joop wrote:
>
>> On Tue, 1 Jul 2003 21:03:17 +0200, uws <uws@xs4all.invalid> wrote:
>>
>>
>>>I <5em2gvkgek7l11vostmsatgdh6flius2fi@4ax.com>, Joop skrev:
>>>
>>>>Is dat zo, bij sendRedirect() word er alleen maar.. ik kom er nu
>>>>achter dat een POST niet eens mogelijk is, want de browser moet de
>>>>post uitvoeren, niet de servlet, want de browser moet de door de php
>>>>genereerde pagina zien.
>>>
>>>Echt waar joh? Heb je enig idee waar je het over hebt? Ik snap er in ieder
>>>geval niets van.
>>>
>>
>>
>> Lijkt me best te snappen, als de servlet een post doet naar php krijg
>> de servlet de response en dus de php pagina, dit terwijl het eigenlijk
>> de client/browser moet zijn die de php pagina te zien krijgt.
>
>Die pagina kan je toch doorgeven vanuit de servlet *naar* de browser?
>Geen enkel probleem.
>
Dat is niet zo efficient, de php pagina word dan opgeslagen in een var
in de servlet en vervolgens naar de browser gestuurd. Maar ik zal eens
kijken wat voor impact dat heeft.
joop
Re: Lange GET parameters?
On Thu, 03 Jul 2003 02:49:48 +0200, John Bokma
<postmaster@castleamber.com> wrote:
>Joop wrote:
>
>> On Tue, 01 Jul 2003 11:37:10 +0200, John Bokma
>> <postmaster@castleamber.com> wrote:
>
>[snip]
>
>> Maar dat gaat juist niet, de servlet kan de query niet uitvoeren, dat
>
>*waarom* niet?
Omdat het c programma het resultaat van de query parsed naar een
plaatje, dit kan een servlet niet, of je moet het c programma
herschrijven naar servlet, maar dat ben je een paar maanden bezig.
>
>> kan alleen php. Het is namelijk zo dat er alleen een php schil bestaat
>> voor een programma wat geschreven is in c wat niet multi threads
>> ondersteund, via php benaderen is dus de enigste optie.
>
>*waarom*? Pas op met threads en zo, ik kan met 2 browsers heel goed jouw
>PHP programma vrijwel gelijktijdig aanroepen... als je c programma of je
>database hiermee niet overweg kan is het einde echt zoek op deze
>manier... Sterker, dan *moet* je misschien wel een servlet gebruiken of
>file-locking vanuit PHP...
Andere mensen gebruiken met succes de php schil op grote websites en
hebben nooit problemen gehad, dus ik kan er van uit gaan dat het met
php gewoon goed gaat.
joop
Re: Lange GET parameters?
On Thu, 03 Jul 2003 03:05:23 +0200, John Bokma
<postmaster@castleamber.com> wrote:
>Joop wrote:
>
>> Dat is met een mutex/sync werken, maar dat is niet de bedoeling, er
>
>Dat is wel de bedoeling. Als je C programma altijd het plaatje naar
>hetzelfde bestand schrijft kom je daar gewoon niet onderuit, tenzij je
>absoluut kan garanderen dat je bezoek *nooit* gelijktijdig komt en nooit
>met meer dan een browservenster. Je programma kan al stuk gaan als je 2
>keer het plaatje in 1 pagina opneemt... (Mooie test overigens, maar als
>ie 100000 keer goed gaat, is dat nog geen garantie, *tenzij* je sync heb
>toegepast).
Klopt, maar dan moet je nog steeds een javaschil schrijven voor pakweg
750 functies :(
>
>> moet via de php schil gewerkt worden, ander moet ik zelf java schil
>> maken en dat kost tijd.
>
>Uitbesteden :-).
Ik wacht liever nog even, ze zijn nu bezig om c programma threadsafe
te maken, dus er zal hopelijk automatisch een javaschil op de markt
komen.
joop