ongevraagde 301 bij ajax post

[shakkie]

Sinds een verhuizing van server a naar server b (ongewenst overigens) ondervind ik wat problemen in een zelfgemaakt CRM systeem. Vrijwel de meeste problematiek is ondervangen maar 1 probleem blijft toch hardnekkig de kop opsteken.

Mijn url structuur is : (domein)/index.php/(classnaam)/functie/parameters
Dit werkt prima behalve wanneer ik een post doe via Jquery.
Voorbeeld :

JavaScript:

$.ajax({
                          type: "POST",
                          url: "http://www.(DOMEIN).nl/M/index.php/configurator/savePdf",
                          data: { data:html, enquete : $(".export").attr("id") },
                          success: function(){
                              $(".status").html('<b>Voltooid</b> Opgeslagen bij de klantkaart.');
                          }
                        });

Dan vindt er het volgende plaats:
Er wordt eerst een GET request uitgevoerd en hieruit volgt een 301. De url is aangepast naar http://(DOMEIN)/M/configurator/savePDF en vervolgens geeft het daadwerkelijk POST request een 404. Dit is natuurlijk te verwachten gezien het verdwijnen van index.php maar begrijp niet goed waar dit gedrag vandaan komt. Ik maak geen gebruik van htaccess dus een de redirect is niet gewenst.

Deze actie heeft altijd gewerkt maar geeft nu dus het bovenstaande probleem.

Ik heb de max_execution_time in de php.ini op unlimited staan, post_max_size op 20M en upload_max_filesize eveneens op 20M maar het mag allemaal niet baten.

Iemand enig idee hoe die 301 kan ontstaan en belangrijker nog, hoe ik ervoor kan zorgen dat het request normaal wordt uitgevoerd? Ligt dit aan de server, Chrome of zie ik iets simpels over het hoofd?

ps. De var html bestaat uit ongeveer 4Mb aan data.

[Room42]

Check de Apache-logs (access én error), check de browser log (daarin worden de requests ook volledig weergegeven) en bouw wellicht wat debugging in het script. Ik heb het idee dat er iets wordt aangeroepen dat jij niet zo had bedacht. En je vraagt of het aan Chrome ligt, dat kun je natuurlijk makkelijk testen door een andere browser te pakken.

[shakkie]

Evanescent. Goede punten!
Debugging heb ik er voor het voorbeeld weer uit gehaald. Uiteraard heb ik de nodige zaken geprobeerd alvorens ik mijn heil hier zocht. Ik vraag expliciet of het aan Chrome ligt omdat de rest van de applicatie om Chrome heen gebouwd is. Browser log kon mij ook niet verder helpen. Het grootste probleem is de omzetting van de request url. Waarom wordt het stukje index.php/ weggelaten in de request? De oorzaak daarvan vind ik nergens terug.

[NMe]

Die vind je dan ook niet in je browser log maar in de access- en errorlogs van de webserver, zoals Evanescent al zei. Heb je daar al naar gekeken?

[HollowGamer]

Aangezien je van domeinX naar domeinY gaat, heb je mogelijk te maken met CORS en moet je bepaalde headers gaan zetten.

Ik moet wel aangeven dat ik het jammer vind dat je de debug opties niet kent, heb je deze nooit geleerd? Zeker niet te oud om te leren, maar deze moet je eigenlijk eerst checken.

[shakkie]

Heel slordig van mij foxgamer2019 en NME en inderdaad, ik ben niet goed bekend in debugging.
Na de logs te hebben geraadpleegd werd ik niet veel wijzer. Echter helpt vroeg opstaan soms en bedacht ik mij dat het wellicht zou helpen wanneer ik de postdata zou omzetten naar een base64 string en voila! De server accepteert kennelijk geen plain html meer.
Bedankt voor jullie hulp en ik ga het debuggen toch maar eens wat uitdiepen

[AW_Bos]

shakkie schreef op zaterdag 22 september 2018 @ 08:15:
De server accepteert kennelijk geen plain html meer.

Dat klinkt wel erg vreemd. Draait er geen vage veiligheidsbarrière op de webserver die HTML blokkeert?

[Voor 28% gewijzigd door AW_Bos op 22-09-2018 09:30]

[shakkie]

AW_Bos schreef op zaterdag 22 september 2018 @ 09:29:
[...]

Dat klinkt wel erg vreemd. Draait er geen vage veiligheidsbarrière op de webserver die HTML blokkeert?

Ja, dat vermoeden heb ik wel. De code draait op een managed VPS en heeft altijd prima gefunctioneerd maar de hostende partij vond het nodig om de boel te migreren en de veiligheid te verhogen. Heel fijn allemaal maar daardoor zijn wel alle settings verloren gegaan en vinden dit soort eigenaardige "foutjes" plaats.
Ik heb geen toegang meer tot de config bestanden en aangezien de persoon die mij opnieuw toegang kan geven kennelijk op vakantie is zal ik het met behulp van wat lelijke workarounds moeten oplossen voorlopig.

[AW_Bos]

Managed door je hosting? Dan is het raar dat er maar een iemand is die verantwoordelijk is voor de configuratie, en die nu met vakantie is.

[Voor 10% gewijzigd door AW_Bos op 22-09-2018 10:22]

[shakkie]

Eens, dat wist ik tot afgelopen donderdag ook niet en baart me best zorgen!

[KabouterSuper]

Ik check mijn redirects met http://www.redirect-checker.org/
Je kunt hier natuurlijk geen post data inzetten, maar url rewrites doen ook niets het post data dus dat zou niet uit moeten maken.

Zo kan je zien dat http://pricewatch.tweakers.net het volgende oplevert:

code:

CONGRATULATION. Everything seems to be fine.

http://pricewatch.tweakers.net
301 Moved Permanently
https://pricewatch.tweakers.net/
301 Moved Permanently
https://tweakers.net/pricewatch/
202 Accepted

[NMe]

shakkie schreef op zaterdag 22 september 2018 @ 10:19:
[...]

Ja, dat vermoeden heb ik wel. De code draait op een managed VPS en heeft altijd prima gefunctioneerd maar de hostende partij vond het nodig om de boel te migreren en de veiligheid te verhogen. Heel fijn allemaal maar daardoor zijn wel alle settings verloren gegaan en vinden dit soort eigenaardige "foutjes" plaats.

Ik ken om eerlijk te zijn geen enkel stukje serverconfig dat at random besluit om /index.php uit een URL te slopen. Om heel eerlijk te zijn lijkt het er eerder op dat je een stukje code hebt dat toevallig werkte in een oudere PHP-versie en in een nieuwere niet meer. De migratie zelf zal het niet zijn. Neemt niet weg dat een host niet zomaar moet migreren zonder overleg en als dat iets stukmaakt zou het ze sieren om de migratie in elk geval tijdelijk terug te draaien, maar da's een ander verhaal.

[mcDavid]

NMe schreef op zaterdag 22 september 2018 @ 13:51:
[...]

Ik ken om eerlijk te zijn geen enkel stukje serverconfig dat at random besluit om /index.php uit een URL te slopen. Om heel eerlijk te zijn lijkt het er eerder op dat je een stukje code hebt dat toevallig werkte in een oudere PHP-versie en in een nieuwere niet meer. De migratie zelf zal het niet zijn.

Dit idd. Of juist andersom, iets wat vroeger niet werkte en nu juist wel.

Zo'n redirect kan op grofweg 3 plekken geïnitieerd worden:
1) de loadbalancer
2) de webserver (apache)
3) de applicatie (PHP).

Die eerste twee kun je héél snel uitsluiten door even in de accesslogs van je webserver te kijken. Die derde (lijkt me het meest waarschijnlijk) door even te testen met een "hello world" scriptje of zo.

shakkie schreef op vrijdag 21 september 2018 @ 23:17:
Ik vraag expliciet of het aan Chrome ligt omdat de rest van de applicatie om Chrome heen gebouwd is.

Dat was toch vrij makkelijk uit te sluiten geweest door even met curl of een andere browser een request te doen?

shakkie schreef op zaterdag 22 september 2018 @ 08:15:
Heel slordig van mij foxgamer2019 en NME en inderdaad, ik ben niet goed bekend in debugging.
Na de logs te hebben geraadpleegd werd ik niet veel wijzer. Echter helpt vroeg opstaan soms en bedacht ik mij dat het wellicht zou helpen wanneer ik de postdata zou omzetten naar een base64 string en voila! De server accepteert kennelijk geen plain html meer.
Bedankt voor jullie hulp en ik ga het debuggen toch maar eens wat uitdiepen

Nu ben ik wel nieuwsgierig wat het dan is. Maar dit duidt er wel op dat er inderdaad in de applicatie zelf iets raars gebeurt!

[shakkie]

Ik ga mij heeeeeel diep schamen....
Het was de LimitRequestFieldSize die de boel tegenhield. Ik heb de postdata opgeknipt en in delen naar de server gestuurd aangezien ik (zoals eerder gemeld) die setting niet kan aanpassen.
Waarom er uiteindelijk een redirect 301 wordt teruggegeven is mij nog wel onduidelijk maar in ieder geval is het probleem opgelost.

[redfox314]

Iedereen die serieus developed eender wat doet heeft wel eens een ‘Oh you moron’ momentje, hoeveel ervaring je ook hebt.

[TomsDiner]

shakkie schreef op zaterdag 22 september 2018 @ 08:15:
Echter helpt vroeg opstaan soms en bedacht ik mij dat het wellicht zou helpen wanneer ik de postdata zou omzetten naar een base64 string en voila! De server accepteert kennelijk geen plain html meer.

Base64 vermijdt lastige tekens... Was die oude server zo oud dat magic quotes nog aanstonden?