difi/begrep-SikkerDigitalPost

SOAPFault og HTTP kode 400 fra MF

Closed this issue · 10 comments

torstenk commented

Vi ber om at HTTP kode som returneres med SOAPFault endres fra 400 (Bad Request) til 500 (Internal Server Error).
Dette for å være i tråd med SAAJ biblioteket til Oracle Java og måten den håndterer kode 400, som er å lage en Exception.

landro commented

SOAP 1.2 spesifikasjonen, som AS4 bygger på, sier i avsnittet "7.5.2.2 Receiving" at man skal returnere en HTTP 400 når "Sender" har gjort en feil. Slik jeg ser det, kan det ha store interoperabilitets-konsekvenser å gjøre en såpass fundamental endring som dere ber om, og jeg ser for meg at det kan føre til store problemer for de som kjøper EBMS hyllevare-produkter, å avvike fra spesifikasjonen.

I meldingsformidleren benytter vi oss også av SAAJ referanseimplementasjonen til Oracle, og har ikke hatt spesielle utfordringer med det.

Når det gjelder selve håndteringen av soap faults (uavhengig av 400/500) eller andre feilsituasjoner (nett etc), er det så vidt meg bekjent, ikke noe som håndteres av SAAJ, men av kode / rammeverk over. Kan dere peke på kode i SAAJ som skulle tilsi noe annet? Hvis jeg var dere, ville jeg tatt dette opp med EBMS-leverandøren deres.

torstenk commented

com/sun/xml/internal/messaging/saaj/client/p2p/HttpSOAPConnection.java

    responseCode = httpConnection.getResponseCode();
   // let HTTP_INTERNAL_ERROR (500) through because it is used for SOAP faults
   if (responseCode == HttpURLConnection.HTTP_INTERNAL_ERROR) {
       isFailure = true;
   }

Vi har ingen problemer med å håndtere SOAPFault som du skriver, bare vi får lest dem.

NB Dette gjelder tilfeller der MF sender ebMS Error signal på feks validering av payload, ikke faktiske HTTP eller SOAP feil.

landro commented

Forstår - det der er jo rett og slett en stygg bug i mine øyne (noe som vel antyder at nesten ingen bruker denne koden i produksjon?). Har dere tatt det opp med support hos Oracle?
Alternativt er det jo en smal sak å patche disse klassene slik at de oppfører seg slik dere vil.
Vi har selv måttet gjøre noen ytelsesrelaterte endringer i SAAJ pga ressurslekasjer og en alvorlig flaskehals.

Vi bruker ikke SAAJ sin klient (HttpSOAPConnection) når vi gjør kall mot f.eks. eboks eller Digipost postkasse. Årsaken er er at http klienten i jdk-en er relativt begrenset i funksjonalitet og ytelse (vi bruker apache http components).

torstenk commented

OK. Sier du at det er en smal sak for dere å patche på deres side, eller at vi skal patche på vår side?

landro commented

Til info, vi har rapportert våre issues med SAAJ her: https://java.net/jira/browse/SAAJ-73
I neste omgang har vi bygget SAAJ selv og bruker service pluggability mekanismen i jdk-en.

landro commented

Jeg sier at det bør være en smal sak for dere å patche på deres side.

torstenk commented

Dette er nå https://java.net/jira/browse/SAAJ-74. I mellomtiden patcher vi dette på vår side.

landro commented

@torstenk, jeg tror Oracle er veldig mottagelige for patcher (dere kan jo f.eks. lage en github fork og kjøre en pull request e.l.). I god open source tradisjon, hadde det jo vært veldig bra om fixen dere gjør flyter tilbake til upstream. På litt sikt vil dette gå inn i jdk-en, og dere slipper å vedlikeholde koden selv samt at andre får glede av fixen.

aberner commented

jeg oppfatter nå at denne problemstillingen følges opp utenfor sikker digital post infrastrukturen og at det ikke gjøres endringer på de HTTP errorkoder som returneres fra meldingsformidler.

Foreslår at saken lukkes.

torstenk commented

Enig i og for seg, jeg ber dog om å holde saken åpen til lunsj i morgen, slik at vi får verifisert løsningen.