Ciao Lorenzo, non ho capito bene cosa hai fatto sull’editor di configurazione: io non ho il FastCgi in system.webServer!
I parametri di timeout del FastCgi però li avevo già alzati, accedendo direttamente alla home page del server -> Impostazioni di FastCgi -> Modifica! Comunque non ho risolto…. 
Ma tu hai IIS7?
iis 8.5, ma il problema si è ripresentato ;(
Ciao roberto,
ti volevo chiedere tu hai provato a mandarti delle richieste soap al tuo servizio?
io ieri ho fatto diverse prove e tutte le richieste sono arrivate correttamente.
Si, si: se provo a mandare delle richieste SOAP con SOAPUI dal mio computer, con un file allegato molto grande, tutto funziona regolarmente! Se lo fa il client di SDI, non funziona… Sto uscendo pazzo….
Se col tuo client funziona, il problema potrebbe essere di comunicazione tra il client che usa l’agenzia (java) e IIS.
Non so se hai già provato questa soluzione (che ho ripescato da una mia vecchia risposta ad un problema simile), ma prova:
https://boyan.io/random-500-errors-iis-client-certificates/
In pratica il client java è più restrittivo sulla configurazione dei certificati e certe volte da un errore se non è impostato correttamente clientcertnegotiation=Enable
Ciao gianluca,
grazie per la risposta 
purtroppo avevo gia applicato questa soluzione, e avevo parzialmente risolto il problema, nel senso che molte richieste andavano in errore senza far scattare il timeout, mentre in queste succede che le richieste vadano in timeout e il modulo fastcgi rimanga in esecuzione 15 min prima di restituire 500
idem come sopra . . . .
ho un piccolo aggiornamento, nella cartella c/windows/temp ho visto i vari temp file del php e riesco a vedere tutti le richieste che non sono andate a buon fine, mi sembra di notare che siano tutti file con allegati e che la richiesta sia troncata appena prima della fine dell’allegato, é possibile? ora sto provando a capire come risolvere se si tratta di questo problema
Beh, sicuramente gli allegati aumentano le dimensioni dei file trasmessi e questo crea il problema! Quindi, mi sembra che non siano gli allegati in sè, il problema, ma la dimensione dei files! Questo l’avevo già appurato da tempo, però ancora non mi è servito per risolvere…
sisi, pero guardando in questi file temporanei ce ne sono di ogni dimensione, dagli 80kb ai 4.07mb(fattura contenente uno zip 
), quindi mi sembra che il discorso possa essere piu legato all’allegato che alla dimensione,
Guarda, abbiamo constatato che noi riceviamo file solo fino a 23Kb! Inserendo un file allegato nel file che ci viene inviato, è facile che questo limite venga superato…
anche io tra le fatture la piu grande che vedo é di 23 kb, ma se vado c:/windows/temp vedo tutti i tmp del php e ci sono tutte le fatture che non ho ricevuto
In effetti questo fatto delle fatture “fallite” in Windows\temp è interessante, significa che comunque le fatture vengono ricevute, almeno in parte…. poi la ricezione si blocca, ho appena verificato anche io…. Per quale motivo??? L’investigazione continua…. 
Ho trovato una soluzione parziale: ho scoperto che i dati ricevuti dal SDI sono presenti “per intero” nei file di log, anche se divisi in più spezzoni di “buffer” ! Pertanto ho realizzato una procedura che fa la scansione dei file di log e acquisisce le fatture che il mio server web non riceve! Il problema è che il mio server non risponde alla chiamata del client SDI per segnalare che le fatture sono acquisite, e quindi per il SDI risultano sempre non consegnate… Pertanto devo continuare a studiare il problema….
C’è qualcosa che si frappone fra l’arrivo delle fatture (registrate regolarmente nei file di log) e il server, dove non arrivano per niente!
Ho notato, dai file di log, che il server si mette in fase “FASTCGI_WAITING_FOR_RESPONSE” e, alla fine del REQUEST TIMEOUT (che posso anche impostare in ore…), il processo di fastcgi viene killato! Insomma c’è qualcosa che non fa mai andare a buon fine la ricezione delle fatture o il lavoro del fastcgi… boh!
Ma mi chiedo, ci sono altri utenti che usano IIS e PHP senza problemi???
Ciao roberto, Grande! ci avviciniamo alla soluzione! grazie mille per la condivisione intanto, sembra che al server arrivi tutto ma nel passaggio dei dati al php succeda qualcosa, che tronchi il file e impedisca al nostro web service di elaborare il messaggio. tra l altro ho anche contattato la microsoft venerdi, che pero mi hanno detto non si occupano di troubleshoting, ma che mi avrebbero fatto contattare da dei tecnici
Avete provato ad alzare il parametro uploadReadAheadSize nella server config ?
Non sono un utilizzatore di IIS ma in alcuni software consigliano di alzare questo parametro per evitare problemi alle estensioni ISAPI… (fastcgi come lo fate girare ??)
A me viene l’atroce sospetto che quei 25k che ottenete non siano altro che 49152 bytes (valore di default del parametro) se codificati in base64…
La tua soluzione rischia di mettere nei casini il tuo cliente…
Se pensa che la fattura che vede sia stata correttamente acquisita e non la va a vedere nel cassetto fiscale fra le mancate consegne, rischia di scaricare dell’iva che non potrebbe invece legalmente scaricare finchè non legge la fattura dall’apposita sezione del cassetto stesso, terminando pertanto il ciclo di consegna della fattura. (almeno questo mi dice il mio commercialista)
si, questo é verissimo, infatti eviterei questo “recupero”, piuttosto fornisci un metodo ai tuoi clienti per fare l’upload delle fatture sul tuo programma.
Ciao romolo, il parametro uploadReadAheadSize purtoppo lo avevo gia sparato al massimo, ormai pensavo di riscrivere il webservice in ricezione in asp.net e vedere cosa succede, ed eventualmente tenermi il metodo in asp.net
Romolo, grazie ma ho già modificato anche io lo stesso valore di uploadReadAheadSize, ma niente da fare.
Riguardo al problema “fiscale”, lo conosco e penso di risolvere con una procedura che scarica le fatture direttamente dalla cartella delle “mancate consegne” del cassetto fiscale. Questo nell’attesa di risolvere il problema principale…
Lorenzo, fammi sapere se con asp.net risolvi, però a me sembra che le fatture non arrivino nemmeno al web service e si fermino prima… vedremo…
1 Mi Piace
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