Trunkering af data o HTTP POST

[mdc]

Jeg har problemer med mit CMS på www.retraete.dk. Jeg har logget nogen fejlende og korrekte opdateringer af sitet med Wireshark. (Se evt. http://www.retraete.dk/index.php?ID=61&lang=da)

Min konklusion er, at noget i serveren trunkerer mine data i HTTP POST hvis de er over en eller anden grænse. Men der kvitteres for data, så TCP/IP trafikken viser ingen fejl i mit seneste forsøg. (Førrste forsøg viste også netværksproblemer, men ikke mere end TCP/IP burde kunne håndtere.)

CMS er fra www.fundanemt.com. Jeg har haft kontakt med hoved-udvikleren på IRC:

<_mdc> Nogen der gider kikke på http://www.retraete.dk/phpinfo.php? Måske en bufferstørrelse er forkert?
<chrsen> kigger lige
<_mdc> Tak, I har verdens hurtigste suport!
<chrsen> max_input_nesting_level - prøv at sætte den op
...
<chrsen> den står da til 64
<chrsen> så sæt den op til 300 eller noget

Er det noget I kan justere på?

Samme data kørt lokalt på mun Ubuntu virker uden problemer. Ved ikke præcis hvad forskellen er på Ubuntus og jeres opsætning, men jeg vedlægger output fra phpinfo() kørt på den.

Men det er surt at skulle hente et sql-dump på netplads.dk, læse det ind lokalt, lave sine rettelser, dumpe den lokale MySQL og lægge data tilbage.  Grin

[mdc]

Her er zippet output fra phpinfo() på Ubuntu, hvor sitet kører fint.

[Calzone]

Jeg poster 3MB JPEG billeder til Web2 uden problemer, så tror ikke lige det er der problemet er, hvad med noget kode man kunne se på og prøve?

Og max_input_nesting_level skulle ikke have noget med dette at gøre, for det vil sige du har nogle variabler du poster der ser noget ala sådan her ud:

$_POST[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21][22][23][24][25][26][27][28][29][30][31][32][33][34][35][36][37][38][39][40][41][42][43][44][45][46][47][48][49][50][51][52][53][54][55][56][57][58][59][60][61][62][63][64][65]

Kan du selv se det ikke virker som om det lige er det der er problemet?

[mdc]

Jeg poster 3MB JPEG billeder til Web2 uden problemer, så tror ikke lige det er der problemet er, hvad med noget kode man kunne se på og prøve?

Og max_input_nesting_level skulle ikke have noget med dette at gøre, for det vil sige du har nogle variabler du poster der ser noget ala sådan her ud:

$_POST[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20][21][22][23][24][25][26][27][28][29][30][31][32][33][34][35][36][37][38][39][40][41][42][43][44][45][46][47][48][49][50][51][52][53][54][55][56][57][58][59][60][61][62][63][64][65]

Kan du selv se det ikke virker som om det lige er det der er problemet?

max_input_nesting_level var den parameter chrsen foreslog at skrue op. - Små slag. 

Jeg er ikke ekspert i HTTP eller PHP, men har faktisk arbejdet med udvikling af andre protokoller og
værktøjer til disse i en del år.

Jeg har et problem, og prøver at indkredse det.

Jeg kan se i de logs der henvises til, at de data min klient prøver at sende, faktisk sendes på linien. Tilsyneladende bliver de trunkeret før de når frem til PHP-koden på serveren hvis de er over en vis længde. Korte opdateringer går fint. Det samme sker ikke på en reference-system, hvor præcis samme kode og database er lagt ind. 

Hvad er så forskellen? Det er det jeg prøver at finde ud af.

Næste trin kunne være at lægge testudskrifter til disk ind i koden på serveren.

Alle tips modtages gerne.

[Calzone]

Uden præcis kode der er det meget svært at løse, så du må komme med et par linier kode der fejler, så må vi debugge der fra.


Og så¨kan du hilse chrsen og bede ham læse PHP manualen, så vil han se hans løsning intet kan have med dette problem at gøre.

[mdc]

Uden præcis kode der er det meget svært at løse, så du må komme med et par linier kode der fejler, så må vi debugge der fra.


Og så¨kan du hilse chrsen og bede ham læse PHP manualen, så vil han se hans løsning intet kan have med dette problem at gøre.

Jeg kender som sagt ikke PHP særlig godt, så jeg tager udgangspunkt i netværkstrafikken, som logget med Wireshark. Starten af dataindholdet i HTTP POST er
---------------
field1%402=%2BbTid-b&field2%402=%2BbSted-b&field3%402=%2BbTema-b&field4%402=%2BbPris-b&field5%402=%2BbArrang%F8r-b&field1%40382=09+-+11+januar&field2%40382=Stella+Matutina%2C+Kokkedal&field3%40382=Weekendretr%E6te&field4%40382=1100+kr.&field5%40382=%7BSankt+Joseph+S%F8strene%7C17%7D&field1%40412=15+-+18+januar&field2%40412=Skovhuset%2C+Sdr.+Vissing&field3%40412=Nyt%E5rsretr%E6te.+%22lad+os+%F8se+vand+af+gl%E6dens+kilde%22&field4%40412=2250+kr.%0D%0AMax+9+deltagere&field5%40412=%7BJette+Dahl%7C37%7D&field1%40383=23+-+25+januar&field2%40383=Stella+Matutina%2C+Kokkedal&field3%40383=Weekendretr%E6te&field4%40383=1100+kr.&field5%40383=%7BSankt+Joseph+S%F8strene%7C17%7D&field1%40419=23+-+25+januar&field2%40419=Skovhuset%2C+Sdr.+Vissing&field3%40419=Et+hjerte+der+finder+ro&field4%40419=1295+kr.&field5%40419=%7BPoul+A.+Beck%7C44%7D
--------------
NB Det er een lang linie, som jeg har taget en del af.

Mappes det i PHPs $_POST til
$_POST[1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16]....

som du mente ikke var sandsynligt? Og som kræver en større værdi af max_input_nesting_level?

Det kunne jo forklare at jeg har set dette problem i 2 omgange efter sitet blev flyttet til netplads.dk

Det er data til en tabel, som vises her http://www.retraete.dk/index.php?ID=60&lang=da

Det går galt når jeg editerer og vil lave save. Editering sker i noget javascript, som har hele tabellen oppe i min browser, og sender det hele tilbage når jeg trykker "save". Serveren (PHP scriptet) klager over at de sidste felter i POST mangler.

På den anden side står max_input_nesting_level også til 64 på min Ubuntu, som sagtens kan køre med samme data.

Jeg vil lige nævne, at den her fejl tilsyneladende opstår uanset hvorfra på internettet der editeres. 4 steder afprøvet.

PS Jeg prøver at få chrsen til at kikke med i denne tråd.

[Calzone]

Har intet med nesting level at gøre, så meget kan jeg sige, så kom med nogle linier PHP koder der laver fejlen.

[mdc]

Har intet med nesting level at gøre, så meget kan jeg sige, så kom med nogle linier PHP koder der laver fejlen.

Du har nok ret 

Jeg har lige sat min Ubuntu til at køre safe_mode og max_input_nesting_level=64 ligesom jeres server. Det giver _ikke_ problemer, jeg kan stadig editere i min kopi af sitet.

Så det er noget andet der er galt. Jeg vil enten lave en lille demo, eller lægge test-kode ind i selve Fundanemt's editor.

[czar]

Du har nok ret 

Jeg har lige sat min Ubuntu til at køre safe_mode og max_input_nesting_level=64 ligesom jeres server. Det giver _ikke_ problemer, jeg kan stadig editere i min kopi af sitet.

Så det er noget andet der er galt. Jeg vil enten lave en lille demo, eller lægge test-kode ind i selve Fundanemt's editor.

vi har selv brugt fundanemt på web2 indtil få ganske kort tid siden, ingen fejl

[mdc]

Ja, jeg undrer mig også. Men mit site kørt hos jer har problemer med at editere store tabeller. Verificeret fra 4 forskellige PCer i DK.

Og når samme data så kører fint her lokalt, valgte jeg at søge efter forskelle i opsætning. Jeg har ikke fundet noget ud over små afvigelser i versioner på PHP, Apache og plugins.

Så nu må jeg enten instrumentere koden så mellemværdier lagres på disk, eller lave en testapplikakation. Problemet er bare at testapplikationen måske bliver for simpel til at provokere fejlen.

Vender tilbage hvis jeg finder noget.

[mdc]

Problemet er tilsyneladende løst. 

Brian Jørgensen (qte) fra Fundanemt foreslog en patch i Fundanemt. Helt præcis i

core/editor/includes/printDialogAddTable.inc

Rettelsen kommer i deres CVS-arkiv.

[czar]

Problemet er tilsyneladende løst. 

Brian Jørgensen (qte) fra Fundanemt foreslog en patch i Fundanemt. Helt præcis i

core/editor/includes/printDialogAddTable.inc

Rettelsen kommer i deres CVS-arkiv.

kan du ikke også bede ham om at patche menusystemet så det ikke komme rmed sqlfejl ved ikke eksisterende menu.. det ødelægger lidt pci certificeringen

[mdc]

kan du ikke også bede ham om at patche menusystemet så det ikke komme rmed sqlfejl ved ikke eksisterende menu.. det ødelægger lidt pci certificeringen

Kan du beskrive problemet lidt mere?

Mener du slettede undersider? Er der en log hvor MySql brokker sig?