Physical Web docs vague about mDNS advertising. I am using Avahi to advertise a global app via mDNS and tried many combinations of service file parameters:
<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name>name-of-service</name>
<service protocol="ipv4">
<host-name>host.name.com</host-name>
<type>_https._tcp</type>
<port>443</port>
</service>
</service-group>
Is there a concrete definition of the form of the mDNS advertisement for physical web?
Related
I have a Windows forms app which uses WCF services. Our application sends messages using one of our WCF services to specific users running our client, so our callback “http:” string is dynamically constructed each time a message is sent to a user. It includes the server IP address and port (126.221.97.105:701) onto which the current user is logged, the user’s id (56281), and the client GUID (7392d27a-e4a0-42e2-89a3-adc332e28934). So, a typical callback “http:” string looks like this:
http://xxx.xxx.xx.xxx:701/CmesCns/CALLBACK/56281/7392d27a-e4a0-42e2-89a3-adc332e28934
We have an http namespace (http://+:701/) on our client and the group “Everyone” is tied to this namespace with all of the access permissions checked (GenericAll, GenericExecute, GenericRead, and GenericWrite). We use “http namespace” to create our namespaces.
Our application has been in production (on Windows Server 2003) for a few years and everything is working fine.
We have recently converted our application to run in the Windows 2008 server environment. The “Target Framework” in each of our projects is set to the “.NET Framework 4.0”. Our application works fine on my Windows 7 developer workstation. That is, I am able to receive messages from our WCF service, but when I place our application onto our Windows 2008 server and I attempt to run the application, I receive the following error message:
"There was no endpoint listening at http://xxx.xxx.xx.xxx:701/CmesCns/CALLBACK/56281/7392d27a-e4a0-42e2-89a3-adc332e28934
that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.”
The http namespace (http://+:701/) exists on my developer workstation and on my Windows 2008 server. The group “Everyone” is tied the namespace on my Windows 7 box and on my Windows 2008 server, and all of the access permissions are checked (GenericAll, GenericExecute, GenericRead, and GenericWrite).
We have been searching the web for an answer but have not discovered anything. Would anybody have any ideas on why this would work on our Windows 7 workstations, but not on our Windows 2008 servers?
Any help is greatly appreciated!
Kevin
When you host a WCF service in IIS you don't specify an absolute url in the address. You should use a relative url to the .svc file. The base url will be determined by the web site where it is hosted.
<service name="WebService.Receptor">
<endpoint
address="/WS.svc"
binding="wsHttpBinding"
contract="IMyContract"
/>
and on the client, depending on how your IIS is configured you should obviously specify the full address:
<client>
<endpoint
name="Receptor"
address="http://MyServer:8000/WS.svc"
binding="wsHttpBinding"
contract="IMyContract"
/>
This assumes that you have configured a site in IIS that listens on the 8000 port and that you have hosted your WCF application inside this site.
if it does not help please follow these links, hope it would be useful.
Stack overflow link
Multiple Endpoint
Typically, this error is because there is no endpoint on the server that matches what the client is requesting (the address, the service, or the authentication is different).
However, in my case, I had the exact same error, and it was not due to any of these things.
When I enabled the tracing on IIS and reviewed the svclog trace with SvcTraceViewer.exe (included in Visual Studio), the actual internal error was "Maximum request length exceeded."
My client was uploading an image via the service. And I guess the image was too big.
To enable tracing I added this to the configuration section:
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="All"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\log\Traces.svclog" />
</listeners>
</source>
</sources>
To solve the error, I increased the message request length in the web config and the error went away.
To do this, in the system.websection in the web.config I added the line:
<httpRuntime maxRequestLength="32768" />
Then I added this section inside the configuration section
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="32000000" />
</requestFiltering>
</security>
</system.webServer>
So I recommend you enable tracing and then review the trace for the exact error.
I have a WCF service that accepts a complex type and returns some data. I want to use Fiddler to see what the incoming requests to the service looks like. The client is .net console app which uses a Service reference proxy. Is this possible with Fiddler. I'm new to this tool and have only used it in the past to post data with the request builder.
You need to add this in your web.config
<system.net>
<defaultProxy>
<proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
</defaultProxy>
</system.net>
then Start Fiddler on the WEBSERVER machine.
Click Tools | Fiddler Options => Connections => adjust the port as 8888.(allow remote if you need that)
Ok, then from file menu, capture the traffic.
That's all, but don't forget to remove the web.config lines after closing the fiddler, because if you don't it will make an error.
Reference : http://fiddler2.com/documentation/Configure-Fiddler/Tasks/UseFiddlerAsReverseProxy
Fiddler listens to outbound requests rather than inbound requests so you're not going to be able to monitor all the requests coming in to your service by using Fiddler.
The best you're going to get with Fiddler is the ability to see all of the requests as they are generated by your Console App (assuming that the app generates web requests rather than using some other pipeline).
If you want a tool that is more powerful (but more difficult to use) that will allow you to monitor ALL incoming requests, you should check out WireShark.
Edit
I stand corrected. Thanks to Eric Law for posting the directions to configuring Fiddler to be a reverse proxy!
Just had this problem, what worked for me was to use localhost.fiddler:
<endpoint address="http://localhost.fiddler/test/test.svc"
binding="basicHttpBinding"
bindingConfiguration="customBinding"
contract="test"
name="customBinding"/>
Consolidating the caveats mentioned in comments/answers for several use cases.
Mostly, see http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/ConfigureDotNETApp
Start Fiddler before your app
In a console app, you might not need to specify the proxyaddress:
<proxy bypassonlocal="False" usesystemdefault="True" />
In a web application / something hosted in IIS, you need to add the proxyaddress:
<proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
When .NET makes a request (through a service client or HttpWebRequest, etc) it will always bypass the Fiddler proxy for URLs containing localhost, so you must use an alias like the machine name or make up something in your 'hosts' file (which is why something like localhost.fiddler or http://HOSTNAME works)
If you specify the proxyaddress, you must remove it from your config if Fiddler isn't on, or any requests your app makes will throw an exception like:
No connection could be made because the target machine actively refused it 127.0.0.1:8888
Don't forget to use config transformations to remove the proxy section in production
So simple, all you need is to change the address in the config client: instead of 'localhost' change to the machine name or IP
This is straightforward if you have control over the client that is sending the communications. All you need to do is set the HttpProxy on the client-side service class.
I did this, for example, to trace a web service client running on a smartphone. I set the proxy on that client-side connection to the IP/port of Fiddler, which was running on a PC on the network. The smartphone app then sent all of its outgoing communication to the web service, through Fiddler.
This worked perfectly.
If your client is a WCF client, then see this Q&A for how to set the proxy.
Even if you don't have the ability to modify the code of the client-side app, you may be able to set the proxy administratively, depending on the webservices stack your client uses.
Standard WCF Tracing/Diagnostics
If for some reason you are unable to get Fiddler to work, or would rather log the requests another way, another option is to use the standard WCF tracing functionality. This will produce a file that has a nice viewer.
Docs
See https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/tracing-and-message-logging
Configuration
Add the following to your config, make sure c:\logs exists, rebuild, and make requests:
<system.serviceModel>
<diagnostics>
<!-- Enable Message Logging here. -->
<!-- log all messages received or sent at the transport or service model levels -->
<messageLogging logEntireMessage="true"
maxMessagesToLog="300"
logMessagesAtServiceLevel="true"
logMalformedMessages="true"
logMessagesAtTransportLevel="true" />
</diagnostics>
</system.serviceModel>
<system.diagnostics>
<sources>
<source name="System.ServiceModel" switchValue="Information,ActivityTracing"
propagateActivity="true">
<listeners>
<add name="xml" />
</listeners>
</source>
<source name="System.ServiceModel.MessageLogging">
<listeners>
<add name="xml" />
</listeners>
</source>
</sources>
<sharedListeners>
<add initializeData="C:\logs\TracingAndLogging-client.svclog" type="System.Diagnostics.XmlWriterTraceListener"
name="xml" />
</sharedListeners>
<trace autoflush="true" />
</system.diagnostics>
I have used wire shark tool for monitoring service calls from silver light app in browser to service. try the link gives clear info
It enables you to monitor the whole request and response contents.
I just tried the first answer from Brad Rem and came to this setting in the web.config under BasicHttpBinding:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding bypassProxyOnLocal="False" useDefaultWebProxy="false" proxyAddress="http://127.0.0.1:8888" ...
...
</basicHttpBinding>
</bindings>
...
<system.serviceModel>
Hope this helps someone.
You can use the Free version of HTTP Debugger.
It is not a proxy and you needn't make any changes in web.config.
Also, it can show both; incoming and outgoing HTTP requests.
HTTP Debugger Free
Use fiddler a Reverse Proxy is the final solution for me.
First, configure fiddler as reverse proxy with REGDIT, like the doc said: https://docs.telerik.com/fiddler/configure-fiddler/tasks/usefiddlerasreverseproxy#configure-fiddler-as-reverse-proxy
1)Click Tools > Fiddler Options. Ensure Allow remote clients to connect is checked
2)Create a new DWORD named ReverseProxyForPort inside HKEY_CURRENT_USER\SOFTWARE\Microsoft\Fiddler2.
3)Set the DWORD to the local port where Fiddler will re-route inbound traffic.
4)Restart Fiddler.
Second, change the client to call service through proxy
for example , here is my client app.config:
<client>
<endpoint address="http://localhost:61236/WeatherForecastService.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IWeatherForecastService"
contract="ServiceReference1.IWeatherForecastService" name="BasicHttpBinding_IWeatherForecastService" />
</client>
change the client to use proxy endpoint address.
WeatherForecastServiceClient client = new WeatherForecastServiceClient("BasicHttpBinding_IWeatherForecastService", "http://localhost:8888/WeatherForecastService.svc");
var data = client.GetData(1000);
client.Close();
Change the localhost in the URL to localhost.fiddler, this small change worked for me.
Also if anyone testing the service from WCF Test Client don't forget to edit the URL in the config endpoint
Right click on the config file
Click Edit with Svc Config Editor
Click on Endpoints and edit the endpoint to localhost.fiddler
Check Start a new proxy while calling method
My WCF service exposes an https AND an http endpoint. Apart from the SSL they are identical. They map to the same code.
The ultimate intention is for external users to connect via https, internal users to use http.
In development this gives me a problem. Cassini, the development web server packaged in VS, hates SSL.
I'm wondering if I can configure the service from code, so when running under Cassini, I would not configure https.
Hence the question - How do I configure the service from code if it is IIS hosted? I'd be very happy with alternative answers on how I can persuade Cassini to NOT complain about the https part of the configuration.
"IIS will take care of spinning up the necessary ServiceHost based on your *.svc file - not a whole lot you can do about that, really."
Not too close to the truth. Exactly in the SVC file of your service there is attribute named Factory. Where you can specify the the class and the assebly where the class is located. This class may be your own descendant of Web|DataServiceHostFactory
So your svc markup would look like this
<%# ServiceHost
Language="C#"
Debug="true"
Service="name.space.myService"
CodeBehind="name.space.myService.svc.sc"
Factory = "name.space.WebServiceHostFactoryEx, assembly.name"
%>
The WebServiceHostFactory will be created for every service hit and will recreate your host the way you want it.
You will also need to inherith WebServiceHost and create it the way you need it with certain endpoins, behaviors, addresses, etc settings - whatever you like.
There is very nice post from Michele Bustamante here
EDIT: I figured out the above link is not working anymore, so here it is another one.
I am using this in IIS hosted enviroment for couple of services that are initialized same way.
When you're hosting in IIS, you're leaving a lot of care taking into the realm of IIS - you cannot really grab a hold of your service in this case.
IIS will take care of spinning up the necessary ServiceHost based on your *.svc file - not a whole lot you can do about that, really.
My solution would be different - externalize the <service> tag in your configuration file (web.config):
<system.serviceModel>
<services>
<service configSource="service.dev.config" />
</services>
</system.serviceModel>
In your dev environment, only expose the http endpoint - so your service.dev.config would look something like this:
<service name=".....">
<endpoint name="default"
address="....."
binding="basicHttpBinding" bindingConfiguration="insecure"
contract="......" />
</service>
Create a second service.prod.config which then contains both endpoints - http and https:
<service name=".....">
<endpoint name="default"
address="....."
binding="basicHttpBinding" bindingConfiguration="insecure"
contract="......" />
<endpoint name="secure"
address="....."
binding="basicHttpBinding" bindingConfiguration="secure"
contract="......" />
</service>
and reference that in your web.config on the deployment server.
I hope this is a quick question. I have a WCF service running on IIS port 4040. I have added the following headers to this service
4040 (non load balanced domain)
4040 localhost
So locally I can reference this service as http://localhost:4040/service.svc and also by the fully qualified domain name. This is no problem for all the services on this machine, I can reference everything by localhost:4040
The issue comes when I try to access it from another server (as we have other apps that need to consume the service)
I get a 404 error, and was wondering whether the service is defaulting to being exposed on localhost loopback (127.0.0.1) therefore cannot be accessed.
The endpoint is defined as such:
<service behaviorConfiguration="ClaimChaseBehavior"
name="Modules.EClaims.ClaimChase">
<endpoint address=""
binding="basicHttpBinding"
contract="Domain.EClaims.DataInterfaces.IClaimChase" />
<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
Notice I don't define an address. The reason for this is to allow us to have a common config file (we are trying to get around defining machine domains/addresses and thus multiple configs)
Is there a way to make the WCF default to the machine IP instead of the loopback connector without defining the actual domain name
Hope this makes sense
Regards
Richard
When you're hosting your service in IIS, the address of the service is defined and controlled by the location of your *.svc file - you cannot override that by defining base addresses or explicit address on your service endpoints.
The service address will always be:
http://machinename/VirtualDirectory/YourService.svc
Marc
Check your web config. Have you spesified that the address of the service is localhost?
EDIT:
On second thoughts, it looks like a firewall problem, is port 4040 blocked by a local firewall?
I'm connecting a WCF client to a group of services all implementing the same contract and all at the same host. I was hoping that there would be a way to combine the endpoint definitions to cut down on configuration clutter. I also would rather not do it programmaticly - just by configuration. Right now, my config has this repeated many times:
<endpoint address="http://hostname/ServiceA.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_MyBinding"
contract="ServiceReference.ISearchService" name="ServiceA">
</endpoint>
<endpoint address="http://hostname/ServiceB.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_MyBinding"
contract="ServiceReference.ISearchService" name="ServiceB">
</endpoint>
// continued for ServiceC, ServiceD, etc
For server configurations, there is some notion of "baseAddressPrefixFilters" that can be used for this purpose - is there anything for client configuration?
There is the concept of a base address in WCF - unfortunately, that only works if you self-host, e.g. host your service in a console app or NT service. However, that only works on the server side - there's nothing similar on the client side. On the client side, you always have to define the complete, full service address your endpoint should connect to.
If you host in IIS, your service address is determined by the server name, the virtual directory (and possibly subdirectories under that) and the name of the *.svc file used to host the service in IIS. This is a fixed system convention and you cannot influence it, unfortunately (.NET 4 will bring some remedy to that).