WCF HTTP 405 Method Not Allowed

[sig69]

We maken hier diverse windows services, waarin we een wcf endpoint starten om bijvoorbeeld handmatig of vanuit andere tools dingen te kunnen refreshen en dergelijke. Deze services zijn eigenlijk allemaal min of meer hetzelfde van opzet, en de configuratie is erg simpel en bijna identiek (een endpoint met een basicHttpBinding en een met een mexHttpBinding). Nu wil ik een web rerefence naar een van deze serivices in een SSIS package toevoegen, dus ik vul de url van de service in IE9 in en ik krijg fijn een "HTTP 405 Method Not Allowed" voor m'n neus. WTF? Na enig speurwerk kom ik op het volgende uit:
• service1: opent prima in IE9
• service2: opent prima in IE9
• service3: HTTP 405 Method Not Allowed in IE9, in Firefox opent hij prima
Ik had toevallig Fidler open staan en daar viel me op dat ik bij service3 in IE9 een header terugkrijg:
Allow: POST. In Firefox krijg ik deze header niet terug.
Heeft iemand dit eerder gehad? Ik kom er echt geen steek verder mee..

[RobIII]

Deze al gezien? Of deze? Of deze? En deze?

[ Voor 60% gewijzigd door RobIII op 19-12-2011 18:45 ]

[sig69]

RobIII schreef op maandag 19 december 2011 @ 18:43:
Deze al gezien?

Ja

Of deze?

Ja

Of deze?

Ook die

En deze?

Uiteraard , maar ik kom geen steek verder.

Het WebGet attribuut zou niet nodig moeten zijn, gebruiken we nergens (wel geprobeerd overigens, je weet nooit..). Het gaat ook niet fout bij het aanroepen van een methode ofzo, maar bij het openen van de service pagina (met de link naar de wsdl). Misschien is het wel een IE9 bug ofzo, maar ja de ssis webreference selector draait op IE, en die vreet het nu dus niet...

[RobIII]

sig69 schreef op maandag 19 december 2011 @ 19:43:
[...]

Ja

[...]

Ja
[...]

Ook die

[...]

Uiteraard , maar ik kom geen steek verder.

Fijn dat je dat allemaal even vermeldt in je topicstart dan.

[pedorus]

Tsja, lijkt mij een kwestie van kijken wat voor request Firefox doet ten opzichte van IE9.
http://stackoverflow.com/...e-9-when-calling-wcf-serv
http://stackoverflow.com/...nd-not-working-with-chrom
Lijken gerelateerd, maar dan omgekeerd.

[sig69]

RobIII schreef op maandag 19 december 2011 @ 20:16:
[...]

Fijn dat je dat allemaal even vermeldt in je topicstart dan.

Sorry dat het lijkt alsof ik m'n vraag hier zomaar neerplemp, dat is zeker niet het geval. Ik was er op dat moment alleen even klaar mee en had een trein te halen..

pedorus schreef op maandag 19 december 2011 @ 20:56:
Tsja, lijkt mij een kwestie van kijken wat voor request Firefox doet ten opzichte van IE9.
http://stackoverflow.com/...e-9-when-calling-wcf-serv
http://stackoverflow.com/...nd-not-working-with-chrom
Lijken gerelateerd, maar dan omgekeerd.

Lijkt er op ja, maar dat gaat allemaal over wcf services gehost in IIS, wat bij mij niet het geval is. Morgen maar weer verder klooien..

[sig69]

Goed, na een fidler sessie van een uur, zal ik de oplossing met jullie delen. In m'n browser vulde ik het volgende in:

code:

http://localhost:8731/Design_Time_Addresses/TestWCFService/

Opeens viel het volgende me op...
Volges fidler stuurt Firefox:

code:

http://localhost:8731/Design_Time_Addresses/TestWCFService

En IE9:

code:

http://localhost:8731/Design_Time_Addresses/TestWCFService/

Firefox haalt dus de "/" weg op het einde! Vervolgens in IE9 zelf de / weggehaald in de adresbalk, en alles werkt
Weer een paar uur naar de knoppen voor zoiets onbenulligs..

[sam.vimes]

sig69 schreef op dinsdag 20 december 2011 @ 10:41:
...knip...
Firefox haalt dus de "/" weg op het einde!

Ben je daar echt helemaal zeker van?
Ik heb dat nog nooit meegemaakt.
Sterker nog, als ik het hier even probeer (een paar willekeurige urls opvragen met een / aan het eind), laat FF die gewoon intact. Dat moet ook wel, want relatieve hrefs in de opgevraagde pagina moeten door de browser worden toegevoegd direct achter de laatste / waarbij alles wat achter die / staat, wordt weggekieperd.

Een url

code:

<a href="RelatievePadNaam">...</a>

relatief ten opzichte van

code:

http://localhost:8731/Design_Time_Addresses/TestWCFService/

wordt dus

code:

http://localhost:8731/Design_Time_Addresses/TestWCFService/RelatievePadNaam

, terwijl die ten opzichte van

code:

http://localhost:8731/Design_Time_Addresses/TestWCFService

zal uitkomen op

code:

http://localhost:8731/Design_Time_Addresses/RelatievePadNaam

.

Wat je wel ziet, is het omgekeerde: als je een url opvraagt zonder / aan het eind en het betreft een directory op de server, geeft de server een permanent redirect (301 AFAIK) naar diezelfde url met een / erachter.