I have a bit of code which is annoying me because it is generating obsolete warnings, but I am wary of removing it because:
a) It works
b) I didn't write it
c) I don't currently have a means of testing it. (ie I don't have access to a machine where it is required)
The code is as follows
System.Net.WebProxy proxyObject = System.Net.WebProxy.GetDefaultProxy();
proxyObject.Credentials = System.Net.CredentialCache.DefaultCredentials;
proxyObject.BypassProxyOnLocal = true;
System.Net.GlobalProxySelection.Select = proxyObject;
The warning message is
Warning 31 'System.Net.GlobalProxySelection' is obsolete: 'This class has been deprecated. Please use WebRequest.DefaultWebProxy instead to access and set the global default proxy. Use 'null' instead of GetEmptyWebProxy. http://go.microsoft.com/fwlink/?linkid=14202'
But, if my understanding is correct, (and assuming that the web service the program is trying to access will never be local) what I really should do is just delete these four lines?
Is this correct, or have a missed something?
PS. I know there is probably a #pragma option to ignore the warning, but I don't really want to go down that route.
Yes I think you are right.
A good way to test this is with Fiddler because one of the things it does (apart from trace http requests) is to automatically set itself up as your IE proxy.
If you run the Fiddler and then the following piece of code
HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://news.bbc.co.uk");
//request.Proxy = null; // uncomment this to bypass the default (IE) proxy settings
HttpWebResponse response = (HttpWebResponse)request.GetResponse();
Console.WriteLine("Done - press return");
Console.ReadLine();
you will see that with no explicit proxy override in the code (as in "what I really should do is just delete these four lines"), the request does indeed pick up the global default proxy from IE, and you will see your request in Fiddler.
Only when you uncomment the null proxy assignment, does the request bypass the global proxy settings and not appear in Fiddler.
So yes - I think you are right; for the default proxy you can remove the explicit proxy code.
Related
Let's say I have a bunch of clients who all have their own numeric IDs. Each of them connect to my server through SockJS, with something like:
var sock = new SockJS("localhost:8080/sock/100");
In this case, 100 is that client's numeric ID, but it could be any number with any number of digits. How can I set up a SockJS router in my server-side code that allows for the client to set up a SockJS connection through a URL that varies based on what the user's ID is? Here's a simplified version of what I have on the server-side right now:
public void start() {
HttpServer server = vertx.createHttpServer();
SockJSHandler sockHandler = SockJSHandler.create(vertx);
router.route("/sock/*").handler(sockHandler);
server.requestHandler(router::accept).listen(8080);
}
This works fine if the client connects through localhost:8080/sock, but it doesn't seem to work if I add "/100" to the end of the URL. Instead of getting the default "Welcome to SockJS!" message, I just get "Not Found." I tried setting a path regex and I got an error saying that sub-routers can't use pattern URLs. So is there some way to allow for the client to connect through a variable URL, whether it's /sock/100, /sock/15, or /sock/1123123?
Ideally, I'd be able to capture the numeric ID that the client uses (like with routing REST API calls, when you could add "/:ID" to the routing path and then capture the value that the client uses), but I can't find anything that works for SockJS connections.
Since it seems that SockJS connections are considered to be the same as sub-routers, and sub-routers can't have pattern URLs, is there some work-around for this? Or is it not possible?
Edit
Just to add to what I said above, I've tried a couple different things which haven't seemed to work yet.
I tried setting up an initial, generic main router, which then re-directs to the SockJS handler. Here's the idea I had:
router.routeWithRegex("/sock/\\d+").handler(context -> {
context.reroute("/final");
});
router.route("/final").handler(SockJSHandler.create(vertx));
With this, if I access localhost:8080/sock/100 directly through the browser, it takes me to the "Welcome to SockJS!" page, and the Chrome network tab shows that a websocket connection has been created when I test it through my client.
However, I still get an error because the websocket shows a 200 status code rather than 101, and I'm not 100% sure as to why that is happening, but I would guess that it has to do with the response that the initial handler produces. If I try to set the initial handler's status code to 101, I still get an error, because then the initial handler fails.
If there's some way to work around these status codes (it seems like the websocket is expecting 101 but the initial handler is expecting 200, and I think I can only pick one), then that could potentially solve this. Any ideas?
I'm using WM9.8. I want to know how to call a GET REST service with path variable like:
http://localhost:8080/client/1 in webmethod.
I can call POST rest service using pub.client.http. But it dosen't work to GET.
Use String varible called "method" to set type of Http request method.
Just put the path variable in the URL and made a substitution to the path variable
e.g: http://localhost:8080/client/%yourPathVariableHere%
Holy cow this is an old question but I just tumbled across it and I thought I might helps somebody else who does.
URLs in webmethods are fixed to a single value, like /client unless you enable watt.server.url.alias.partialMatching=true
After that, you can simply alias a service to /client and all subURLs like /client/1 are sent to that service. You still have to parse them to get the ID out.
Be careful, though, because ALL sub URLs are sent to the service. So after enabling this flag I get /client, /client/1, /client/1/name all going to the same service. You can see how this can quickly become REST-unfriendly.
I need your help with the gwt requestfactory
considering following scenario:
I get an existing entity (let's say a invoice) from the server:
InvoiceEntityProxy invoice = request1.getInvoice();
I want to make some changes, so I edit it with a new request:
InvoiceEntityProxy editableInvoice = request2.edit(invoice);
//make some changes to editableInvoice
Now I send the changes made with the second request to the server, to create a preview:
request2.createPreview(editableInvoice);
When the request is sent, the invoice proxy is frozen and I re-enable editing by assigning the proxy to a new request:
editableInvoice = request3.edit(editableInvoice);
If everything is okay, i want to update the proxy and send it to the server, using the latest request:
request3.update(editableInvoice);
But the changes never arrive on the server, because the latest request (request3) doesn't know anything about the changes made to the proxy assigned to the request2.
I thought about following solutions:
I could redo the changes on the latest proxy. But for that, I've to iterate over all attributes and set them again (not very friendly solution, because I've to adjust the method each time I add some attributes to the proxy)
Another approach would be to send the proyx without an id to the server and send the id as second parameter of the update-method. But this would be a shame, because not only the deltas would be sent to the server (which is one of the greate features of the requestFactory).
So what is the best and most common practice to let the request3 know about the changes already made to the proxy, when it was assigned to another request.
You simply forget to call fire(). Example
request2.createPreview(editableInvoice).fire();
Bear in mind that if the following request depend on the result of the previous one, you should put your code in the OnSuccess methode because the request is asynchronous
It's also possible to append multiple requests
EDIT
It important to use the same request for the edit and fire operations. So replace this line
request.update(editableInvoice);
with
request3.update(editableInvoice);
Nice! I found the solution for my problem.
I still have an instance of the original proxy, because the edit() method of the context always return a new instance of the proxy. So I save the original proxy before sending any request.
After each successful request, I re-enable editing the proxy by call the edit method again:
editableInvoice = request3.edit(editableInvoice);
Now the crux:
I can set the original proxy of a proxy, which is used to consider if it changed and what changed. This is done by using AutoBean and set the PARENT_OBJECT Tag like this:
AutoBean<InvoiceEntityProxy> editableInvoiceBean = AutoBeanUtils.getAutoBean(editableInvoice);
AutoBean<InvoiceEntityProxy> originalInvoiceBean = AutoBeanUtils.getAutoBean(originalInvoice);
editableInvoiceBean.setTag(Constants.PARENT_OBJECT, originalInvoiceBean);
On the next request all changed properties are send to the server again.
Thank you for your help and thank you for the hint with the AutoBean #Zied Hamdi
You also can use AutoBeans to duplicate the object before you start changing it. You can keep the original one untouched then request.edit() it and apply changes (introspection like changes) from the "dirty" object.
You'll maybe have to do some research on how to handle EntityProxies since they are "special AutoBeans" : I had to use special utility objects to serialize them to json (available in GWT). So there might be some special handling in doing a deep copy too.
There is an issue maybe with GWT keeping only one version of each EntityProxy (I never checked if it is global or only in the context of a request)
I've asked this question over on programmers that's linked to this one. I'm trying to find a suitable header, that is unlikely to be stripped, that I can use to send back a unique Request ID with every response, even if it does not send a body.
One of the headers I considered was the Pragma header, as looking at the spec it appears to be intended not only for the additional no-cache HTTP 1.0 backwards-compatibility value, but also for application-specific values, so I should be able to use it. It should be possible, for example, to send something like no-cache; requestid=id.
So in a DelegatingHandler I tried writing to it with my ID:
//HttpResponseMessage Response;
Response.Headers.Add("pragma", "some_value");
But it arrives at the client with no-cache; always. I think WebAPI automatically sends caching headers consistent with caching being switched off, which includes the Pragma one.
So, how do I make sure my value is maintained and not overwritten?
I've cracked it, the answer is to make sure you also set the CacheControl header on the HttpResponseMessage, which then bypasses some slightly fishy logic in System.Web.Http.WebHost.HttpControllerHandler (I've opened a discussion on CodePlex about this; I think the logic needs to be changed).
So instead of
//HttpResponseMessage Response;
Response.Headers.Add("pragma", "some_value");
You have to do:
Response.Headers.CacheControl =
new System.Net.Http.Headers.CacheControlHeaderValue()
{
NoCache = true
};
Response.Headers.Add("pragma", "some_value");
(I've used NoCache since the current API default is to switch caching off for all responses).
Is there a way to have Fiddler use an HTTP-delivered file as the response when using the AutoResponder?
I have an AutoResponder rule set up similar to this:
If URI matches...
http://www.liveserver.com/scripts/javascript_file.js
then respond with...
http://internal-dev-server.ext/scripts/javascript_file.js
so that I can QA a different JavaScript before publishing it live.
But responses via HTTP ways return a 404 error. Specifically:
Fiddler - The file C:\Users\me\Documents\Fiddler2\Captures\Responses\http://internal-dev-server.ext/scripts/javascript_file.js was not found.
I get the same thing even if I start the request and response with "EXACT:"
Supported in v2.3.2.5, currently in Alpha form # https://www.fiddler2.com/dl/fiddler2alphasetup.exe
You can either use the HTTP/HTTPS URL directly, or you can use syntax like:
*redir:http://othersite.com/whatever
The advantage of the REDIR syntax is that the server will return a 307 response so that the new outbound request bears the cookies and other information for "othersite.com" instead of "originalsite.com". This may or may not be desirable.
Alternatively, the HOSTS option on the Tools menu is one way to achieve this; the alternative is to type urlreplace partialurlstring1 newpartialurlstring2 in the QuickExec box under the session list. Or write a rule inside Rules > Customize Rules. See www.fiddler2.com/fiddler/dev/scriptsamples.asp for examples.