org.apache.axis2.AxisFault: HTTP ( 500 ) Internal Server Error address : https://26.2.162.231:80

Ciao roberto, ho una piccola novita.
Invece di provare a implementare il servizio in asp.net, ho fatto questo esperimento:
ho impostato il php per essere gestito da cgi e non da fastcgi, a questo punto la fattura é arrivata, ma il server ha restituito errore 502.1…adesso ho provato ad aumentare il tempo di timeout di cgi e vediamo cosa succede.
Aggiungo un altro particolare strano, nei log é stato registrato esattamente 3 ore dopo(alle 14.42), ma la gestione era stata fatta alle 11.42

Fammi sapere, ma sembra un problema simile al fastcgi, nel senso che l’elaborazione inizia quando il server riceve la fattura, registra il file ricevuto nel file di log, appare il messaggio “FASTCGI_WAITING_FOR_RESPONSE” e poi non succede più niente: infine si interrompe quando si raggiunge il timeout; quindi, se si imposta il timeout con un valore molto alto, non si fa altro che ritardare un inevitabile ko……
Io invece in questi giorni ho provato a cambiare sia server web che sistema operativo! Ho provato prima con Apache su Windows e poi con Apache su Linux (ma sempre lo stesso codice php…): sempre lo stesso dannato problema! Cambia la dicitura dell’errore che mi restituisce l’ambiente di test dell’agenzia delle entrate (sto utilizzando un ambiente di test per fare le prove), ma la sostanza è sempre la stessa: ricevo le fatture di piccole dimensioni ma non quelle un po’ più grandi! Sto impazzendo…… A questo punto mi viene da pensare che possa essere colpa del codice, ma perché solo per il file piccoli???

un problema di codice pero dovrebbe almeno iniziare ad eseguirlo, mentre con il fastcgi non iniziava neanche ad eseguire codice, mentre ora ha fatto tutto correttamente, e probabilmente ha anche restituito er01 al sdi, ma non ha avvisato iis di aver completato la procedura restituendogli bad gatewat 502.1…lunedi con il cliente che ha ricevuto controlliamo anche se nel suo cassetto fiscale questa fattura é tra quelle messe a disposizione

Si, questo fatto del codice che non viene eseguito per niente vale anche per me, ma se si trattasse di qualche limitazione del php riguardo alla lunghezza della stringa di input del metodo RiceviFatture?
Con il CGI, invece, entra nel metodo ed esegue il codice, da quello che hai potuto verificare? Ne sei certo?

Mi spiegate perchè soffrite con PHP su IIS anzichè usare ASP ?
Ma farvi un server linux per usare php su apache è troppo complesso ?

1 Mi Piace

Romolo, non hai letto con attenzione quello che ho scritto poco fa… :wink:
Ho provato con Apache su Linux, ma niente da fare! Stesso problema…. :frowning:
Per questo mi sta venendo da pensare che sia un problema di php! Non credo sia possibile creare un server web in asp classico; si può fare senz’altro in asp.net, ma non sono ferratissimo….

Con PHP su linux sotto apache non ho problemi…
ho usato come classe per i test : https://github.com/italia/fatturapa-php-sdk/tree/master/SDICOOP
ma adesso sto provando questa: https://github.com/taocomp/php-sdicoop-server

implementato con asp.net ti faccio sapere roberto, non ero ancora riuscito a sbirciare e a studiarmi un po’ asp.net, in questo weekend ho visto come fare, e con WCF é molto molto semplice

stesso problema…non so piu cosa fare, non ho trovato traccia neanche nei trace

Stesso problema sia con ASP.Net che con CGI ??? Non ci posso credere…… :-:flushed:

dai log http :
#Fields: date time s-sitename s-computername s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs-version cs(User-Agent) cs(Cookie) cs(Referer) cs-host sc-status sc-substatus sc-win32-status sc-bytes cs-bytes time-taken
2019-02-25 01:29:39 W3SVC1 ---------- ------------- POST /fatturazione/ricezione - 443 - 217.175.52.231 HTTP/1.1 IBM+WebServices/1.0 - - ----------:443 500 0 14 1450 114577 1390
questo punto penso sia un problema sui certificati, non so piu cosa pensare, tu come li hai impostati, mapping manyToOne?

Per la verità all’inizio stavo avendo problemi a configurare il certificate mapping, per cui ho provato a non abilitarlo per niente e tutto sembrava funzionare regolarmente, sia in fase di test che in produzione! Adesso che però ho questo problema di file di dimensioni più grandi, in effetti stavo pensando di rivedere anche questa aspetto, anche se restano due perplessità:
1 . se fosse un problema di certificati, non dovrebbe funzionare mai, indipendentemente dalla dimensione della request ricevuta, credo… (ma chi lo sa…)
2. su Linux esiste la configurazione del certificate mapping? Non ne ho mai sentito parlare, l’ho sentita solo per IIS: ad ogni modo la ricezione dei file grandi non funziona nemmeno su Linux!
Cmq è una strada che si può tentare, a questo punto, nella disperazione….
Per il momento sto tentando con il codice PHP che mi ha suggerito Romolo, ti faccio sapere.

già che ci sei verifica di aver configurato php con mod_php e non come fastcgi…
Vedi: Problemi ricezione fatture SDICOOP Apache PHP-FPM

Per IIS forse anche questo aiuta…

Ciao, c’è una importante novità! Come anche suggerito da Romolo, ho provato a scaricare il php con mod_php (sarebbe la versione Thread Safe per windows) e ad installarlo sul server Apache…: ebbene così FUNZIONA! Ricevo le fatture di tutte le dimensioni senza alcun problema! Quindi, in qualche modo, sono proprio il CGI o il FASTCGI che rompono le scatole!!! Anche su Linux!!!
Pertanto, sullo stesso server Windows, ho IIS per il mio applicativo e l’invio delle fatture e ho Apache per la ricezione di fatture e notifiche da SDI: è un giro pazzesco ma è l’unico che funziona, per il momento, per cui me lo tengo…. :wink:

Ciao roberto, ma ha i per caso provato anche il thread safe direttamente da iis, php stesso sconsiglia thread safe per windows

No, non l’ho provato, anche perché il php, su IIS, comunque dovrebbe passare dal CGI o dal FASTCGI, e quindi saremmo punto e d’accapo….
L’ho provato solo con Apache, anche se, anche con questo, in genere consigliano di installare il PHP in CGI, ma chi se ne frega! :wink: L’importante è che funziona la ricezione delle fatture! Ho provato ad importare fatture da 2Mb e ha funzionato molto velocemente….

Grandissimo, allora provo anche io e ti faccio sapere, hai configurato apache come indicato da romolo vero?
Grazie mille intanto roberto e anche a romolo! vi faccio sapere

Fantistico funziona tutto!

Onestamente con php 7.2 e la precompilazione del bytecode da parte dello zend engine non vedo molti miglioramenti su un web server apache ben settato fra mod_php e php-fpm + mod_fastcgi, anzi spesso vedo peggioramenti a livello di compatibilità ad usare quest’ultima accoppiata.
Certo se uno ha pochi processi di apache attivi, poca memoria e basse max_request per server ovviamente lo startup overhead di un processo di apache può avere costi significativi, ma se ben settato mod_php è quello che offre maggiori compatibilità e possibilità di tracciamento dei problemi.

Per FastCGI è necessario configurare un’impostazione del FastCGI stesso sulla grandezza massima del payload. Non è sufficiente modificare il parametro di PHP e quello del webserver (quest’ultimo in genere già molto elevato di default).