-
Notifications
You must be signed in to change notification settings - Fork 289
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WSDL returns HTTP 400 if application is hosted on sub path in IIS #741
Comments
Can confirm this. Actually what is strange is that I have the service endpoint configured like this
With this in launchSettings.json
So I'm saying to host it The WSDL is also made available at https://localhost/COREWCFSERVICE1?singleWsdl |
I've been having what I'd suspect is the same issue with self-hosting - I'm working on drop-in replacement CoreWCF code to replace old WCF. In WCF I can have an endpoint http://localhost:1234/Test which will serve the help page. With CoreWCF a base address of http://localhost:1234/Test and the endpoint address empty leads to service calls working but a 400 for the help page. If I add something as the endpoint address the help page then works, but of course the client URL has been changed. Edit: I just tried something else and bingo - I had added a URL to serviceOptions.BaseAddresses as per the blog post on metadata, and once I removed this and set the endpoint address to /Test it worked as expected. Maybe that blog post needs a revision...? |
I'm also running into this issue. |
Having the same issue. Whats the workaround/solution here? |
I can confirm this issue and that following settings does work around the error:
|
If the application is hosted on a sub path in IIS, any request to the WSDL returns HTTP 400.
I narrowed this down to the following code:
CoreWCF/src/CoreWCF.Primitives/src/CoreWCF/Channels/MetadataMiddleware.cs
Lines 176 to 184 in c92ca1a
Due to the AbsolutePath!="/" check, metadataExtension.HttpGetUrl (which is only the URL to the application itself without the service path) is used instead of fallbackHttpEndpointAddress (which would actually be the correct URL including the path to the service).
This later causes the check here to fail and not handle the metadata request.
CoreWCF/src/CoreWCF.Primitives/src/CoreWCF/Description/ServiceMetadataExtension.cs
Line 1065 in c92ca1a
I currently worked around this by setting dummy absolute URLs on the ServiceMetadataBehaviour, although I'm not sure which negative side effects this could have (the URLs in the WSDL and help page are still correct).
This is with CoreWCF 1.1.0 .
The text was updated successfully, but these errors were encountered: