Errore Http 400 Ricezione fattura SDICoop

Ciao a tutti.

Scrivo questo post per condividere un’esperienza che stiamo avendo in fase di ricezione fatture tramite canale da noi sviluppato SDICoop.

Le fatture arrivano regolarmente sui vari codici destinatari creati e assegnati al nostro canale.
Capita però a volte che dei nostri clienti ricevano notifiche di mancata consegna (trovando quindi la fattura nel cassetto fiscale) sul canale dove altre fatture invece arrivano regolarmente.
Aprendo un ticket e chiedendo la ragione tecnica mi hanno risposto (dopo 3 giorni dall’apertura del ticket sul portale ma con una certa celerità dopo il primo contatto) che tutte le fatture che non sono arrivate hanno riportato il seguente errore:

org.apache.axis2.axisfault: Http 400 https://26.2.162.231:80

e scaricando, in buona sostanza, la responsabilità al mio servizio.

Cercando la sintassi dei codici Http il 400 “Bad Request” identifica un problema della sintassi della chiamata. Quindi in teoria il problema sarebbe loro.

Qualcun altro ha avuto o sta avendo questo tipo di problema?? Se lo ha risolto, potrebbe consigliarmi qualcosa?

1 Mi Piace

l’errore loro lo vedono così perchè il tuo Web server risponde in HTML a un LORO problema, ne siamo pieni tutti.
Usi IIS?

guarda la altre discussioni mie, probabilmente è un problema di autenticazione anche il tuo. Hanno una piattaforma di gestione delle CA e dei certificati client con cui negoziano l’SSL che è piena di problemi per il resto del mondo che non sia Websphere…

sì uso IIS e l’applicazione è un servizio WCF sviluppato in .Net.

La cosa che non capisco (e che un po’ mi convince però che non è colpa mia) è che altre fatture arrivano sul canale correttamente, anche nello stesso lasso di tempo.

Poi mi pare che sia un’altra l’eccezione HTTP in caso di non autenticazione: 401 se non sbaglio.

benvenuto nella bolgia allora

non è colpa tua, è colpa loro. Per esempio a me le notifiche di spedizione arrivano sempre, solo le FT in entrata ogni tanto hanno problemi (altri server lato loro?).

l’errore è 403. Se attivi il trace dei fallimenti scommeto che troverai il tuo bel 403.7 anche tu

Se l’errore è randomico prova a dare unn occhio qui [RISOLTO]RicezioneFatture Errore 403 sub 7 random … Io ho risolto…

Ho controllato il trace ed è proprio 400 :roll_eyes:

Scrivo qui di seguito un estratto, ho oscurato io l’indirizzo ip del server

2019-01-21 13:35:50 [server-ip] POST /SDICoopP2k/RicezioneFatture.svc - 443 - 217.175.52.231 IBM+WebServices/1.0 - 400 0 0 218

si, al 90% è il problema che Sogei sta generando a tutti.

attiva il trace e vedrai che è un 403.7

Scusami ma non sono espertissimo con IIS.
Io ho attivato il Logging dell’applicazione web dal pannello usando l’IIS.
Ci sono altre cose da abilitare per vedere se il valore è quello che mi dici? Io continuo a ricevere 400.0.

Ma tra l’altro, a prescindere dall’errore, sono consapevoli quelli della Sogei che è un problema loro e che devono risolvere? All’ultimo ticket mi hanno un po’ liquidato come fosse colpa mia…

Enable Failed-Request Tracing

al supporto rispondono con l’arroganza di chi non sa niente ma si sente ministeriale

non so se a Sogei sanno il casino che stanno facendo su questo punto, e ho il sospetto che la madre di tutti i problemi sia il Websphere IBM che mi pare stiano usando. Come il fatto che non supporti lo SNI nelle chiamate HTTPS che fanno, allucinante nel 2018 ma a loro non frega niente.

Ok grazie. Non avevo installato la funzionalità.
Vedremo cosa viene fuori.
Grazie nel mentre.

Ciao a tutti,
ho lo stesso identico problema di @giorgiodipietro , avete per caso trovato la soluzione?
stesso 400, Sogei dice che è colpa nostra

grazie infinite, stiamo impazzendo

alcuni l’hanno risolto con un po’ di workaround, cerca nel forum

a me per esempio continua a non andare bene. E il problema nasce da LORO!

prova a fare netsh http show sslcert e dimmi cosa hai nel binding di quel sito…

Ciao @mr77, io recentemente ho fatto una modifica al mio servizio per un problema che avevo in consultazione e da una settimana a questa parte non ho più avuto problemi.
Ho aumentato di molto le dimensioni del buffer e di altri parametri del binding, vi giro qui di seguito la modifica da fare al binding nel webconfig.

<binding name="RicezioneFatture_binding" maxBufferSize="2147483647" maxReceivedMessageSize="2147483647" maxBufferPoolSize="2147483647" receiveTimeout="00:59:00" sendTimeout="00:59:00" openTimeout="00:40:00" closeTimeout="00:40:00">
                      <security mode="Transport" />
                <readerQuotas maxDepth="2147483647" maxStringContentLength="2147483647" maxArrayLength="2147483647" maxBytesPerRead="2147483647" maxNameTableCharCount="2147483647" />
                </binding>

La cosa strana è che l’errore preciso sarebbe il 413 ma dalle chiamate vedo il 400, però effettivamente all’oggi non è più successo.

fammi capire, perchè è interessante: tu avevi i 403.7 e li hai risolti aumentando i buffer di WCF? Quindi con una soluzione totalmente estranea all’autenticazione del client?

In realtà, come ho sempre scritto, non avevo il 403.7 ma sempre e solo il 400.
Anche attivando il trace dettagliato, il problema è sempre stato il 400.

Comunque potrebbero essere collegati, potresti comunque provare ad ampliare il buffer. Alla peggio rimane più capiente.

dicevo così perchè in effetti tutti nei log IIS vediamo 400, poi solo il trace ci indica 403.7

ho fatto la tua ipotesi anche io un paio di gg fa e ho riconfigurato WCF per soglie molto più alte. E’ possibile che la causa sia lì e poi si incarti qualcosa nella pipeline interna riportando all’autenticazione, anche se è strano perchè quella dovrebbe essere chiusa molto prima di far partire l’handler del WCF.
Da allora non ho avuto errori, ma onestamente sto ricevendo pochissimo (e su SDI vedo da giorni FT in ricezione da trasmettermi che ancora non hanno provato a mandare quindi sono bloccati loro) quindi non canto vittoria.