Is the "Use Proxy" option on an HTTP Connection in SSIS 2012 broken when not using credentials?
I have a Web Service task in SSIS 2012 that works well normally. When I modify its HTTP Connection to use a proxy without credentials, it seems to ignore my choice and not use the proxy at all. When I specify credientials, it then uses the proxy.
To figure this out, I set it up both ways, and ran Fiddler with capture off. Fiddler with capture off will still show traffic specifically routed through it as it acts as a proxy.
Below are the screenshots with details. You should be able to reproduce this.
First, I note the port that Fiddler is set up with:
Then, I leave Fiddler running but not capturing:
Then I set up the HTTP connection to use the local Fiddler proxy explicitly:
Then I run the Web Service task, and note that nothing shows up in Fiddler.
This tells me that, in this case, SSIS isn't actually using the Web Proxy as I asked it to. Anyone know why not?
To be sure it is working otherwise, I then set up the HTTP connection to use the local Fiddler proxy explicitly, but this time with credentials.
Then I run the Web service task, and note that the request now appears in Fiddler, as expected. So what was wrong in the earlier example?
It looks like the only way is to make the user name and password blank, but leave the box checked. I was surprised when this worked. I am not sure if this is related to how my particular proxy is set up, so your results may vary.
In the context of a unit test I need to send some code to the console of a chrome app I am developing. It's clear that I can do that from the chrome.debug API, but is there a way to do that from outside the browser?
Yes, there is a way; if you can do something with chrome.debug you can do so with remote debugging.
You need to enable remote debugging with command line switches; you can then connect to Chrome with a debugger client instance.
Google lists some existing debugger clients, and you can implement your own by following the debugger protocol (which works over HTTP+WebSockets).
The procedure for a debugger client is to request /json from the debugger port over HTTP, which lists all possible debug targets; the client then connects to the WebSocket associated with that target to work with it.
I have an extension that uses native messaging to launch a server. It
sends a message through the native messaging API which launches a host
process; the host process launches an HTTP server on an ephemeral port
and sends the port number back to the extension; the extension then
connects to that port. All of this works fine.
I am attempting to generalize this mechanism in two ways, and cannot
figure out how to do it.
(1) I would like to allow multiple applications to communicate with a
single installed native messaging host. Currently, each application
needs to install its own host which is configured with information
about the application (basically contains all the code for a "server"
for that application). I would like to use a single host which can
serve arbitrary applications.
(2) I would, thus, like to be able to start the process by having the
application connect to the native messaging host and provide it with
the installation directory of the extension. Then I'd like the native
messaging host to be able to read that directory looking for
configuration information, code, etc. so that it can initialize itself
appropriately. Basically, I'd like the native messaging host to be
able to run code and scripts bundled with the extension, in arbitrary
data formats (in my case, probably plain text, JavaScript files, and Java JAR/class
files) to implement the "server" or "native" portion of the
application.
Given that NPAPI plugins are supposed to be re-implemented using the
native messaging API, I am assuming that this is possible and that I
just can't figure out how to do it.
The only approach that I've come up with that might work seems overly
complicated and underperformant -- basically, I believe I could allow
the host to load code from the extension by having the host send a
"request" to the client (by posting a JSON message, with a request ID and a path, say), and having the client use XMLHttpRequest with ArrayBuffer (in the most general case)
to its own chrome-extension:// URL (as obtained by chrome.runtime using the path as the argument to getURL) to
read its files, serializing them back to the host as JSON. Would this
work? Is this the intended approach?
I am trying to get a simple web page server from within a Google Chrome Packaged App. There is already a UDP server running within the app and working without any problems.
I am starting the socket.listen on 0.0.0.0:8080 and copying most of the code from
https://github.com/GoogleChrome/chrome-app-samples/tree/master/webserver
. The same issue is replicated in the sample app.
What I am doing is accepting the request and sending a single HTML file to all requests which have some data in the request (request.data.length > 0). The flow of the app is similar to the sample app with near-equivalent functions.
To test this I am using Socket Test 3.0 (from SourceForge). Creating a socket to 127.0.0.1:8080 and sending it GET / HTTP/1.1 as the content. As intended the Chrome App responds with the html file and correct headers. I can repeat this multiple times without restarting the App. The problem arises when the App is sent a request through Chrome. On first look it works as intended, but then it Time Out on refresh. This is also replicated in the sample app.
On debugging I found that every thing was being handles. The write socket being destroyed and a socket.accept(serverSocket, ...) being issued. I also made sure that it was done inside the callback function of the socket.write. The first request as intended is for the page requested (GET / HTTP/1.1 for localhost:8080). Second was for favicon.ico as GET /favicon.ico HTTP/1.1. And then a third connection with none in data (which is then ignored and socket destroyed). Unlike in the SocketTest where every request was answered back.
I have created a video showing the screencast while reproducing the error on YouTube. Also the repo for the project that I'm working on is at GitHub.
I had the same issues with Google's sample web server. I wrote a more robust socket server app that does not hang. The source is on GitHub at https://github.com/kzahel/web-server-chrome and you can install it from the Chrome web store at https://chrome.google.com/webstore/detail/web-server-for-chrome/ofhbbkphhbklhfoeikjpcbhemlocgigb
Sorry for the subject line sounding like an even nerdier Harry Potter title.
I'm trying to use AS3's Socket class to write a simple FTP program to export as an AIR app in Flex Builder 3. I'm using an FTP server on my local network to test the program. I can successfully connect to the server (the easy part) but I can't send any commands. I'm pretty sure that you have to use the ByteArray class to send these commands but there's some crucial piece of information that I'm missing apparently. Does anyone know how to do this? Thanks!
Dave
The FTP protocol predates UTF encoding. Switch to ANSI/ASCII for better results. If you do opt for writeMultiByte instead of writeUTFBytes, be aware that it is buggy in linux. Here's one way around it.
There's another question here where the line ending turns out to be the culprit, so make sure that you get it right (as suggested above).
As said before, if this is running from the web, all socket connections will require a crossdomain policy, but this is NOT file based over HTTP. Recent changes to the security rules mean that any socket based connection must first get a crossdomain from a policy server hosted on port 843 of the target host.
Quoting from Adobe:
A SWF file may no longer make a socket connection to its own domain without a socket policy file. Prior to version 9,0,115,0, a SWF file was permitted to make socket connections to ports 1024 or greater in its own domain without a policy file.
HTTP policy files may no longer be used to authorize socket connections. Prior to version 9,0,115,0, an HTTP policy file, served from the master location of /crossdomain.xml on port 80, could be used to authorize a socket connection to any port 1024 or greater on the same host.
Essentially, what this means is that you must be in control of the target FTP host, and install supplementary software on it to get this working.
Read this link too and maybe it can be useful this one too.
The first one is about policy files and the second is an example of a TELNET (so, no FTP here) client.
I've been able to get an FTP client working in a browser, but it's buggy. I had to get a listener running on port 843 to server the policy file so that Flash would be allowed to connect and transfer data. Then, I had to figure out how FTP actually works:
You have to open 2 sockets: a command socket and a data socket. The command socket is where you send your USER, PASS, CWD, and STOR commands. The data socket is where you write your ByteArray data to. Sending the PASV command will tell you what port your data socket must connect to.
Where it is buggy is on Mac, in both Safari and FF, when I call the "socket.close()" command, the server socket actually closes. On Windoze, it does not. This is a huge problem because the Event.CLOSE event is not fired until the SERVER closes the connection. This is in the livedocs.
This is where I'm at. I have no idea why it would work flawlessly on Mac and then be completely busted in 3 different browsers on Windows. The only thing I can come up with is that it's either something in my Windows configuration that's preventing proper communication with the server, or it's the Window Flash player that's causing the problem.
Any thoughts?
We will need more info to resolve this.. What you're saying here appears correct to me. You're using the Socket class to send data though, not ByteArray.
Are you sure data is not being sent? How are you receiving the response? It may be that it's working fine but you're just not aware of it? As i said, tell us more about what you're doing..
Lee Brimelow has a screencast on gotoAndLearn of writing an POP3 client. It's essentially the same of what you're doing so take a look.
Are you 100% sure the syntax is correct? I know with HTTP you'll have to an include extra linebreak after the request for it to go through. Without it you'll get nothing back. Not sure how it is with FTP though.
The FTP standard requires CRLF at the end of commands. Try using "\r\n" in place of the "\n" in your example.
You must serve the CrossDomain Policy File from your FTP server in order to conect correctly.
From what I've gathered, you have to send each command one at a time and validate the response before moving on. You should be getting something back against ProgressEvent.SOCKET_DATA
Try just this and see what you get in response.
socket.writeUTFBytes("USER "+user+"\n"); socket.flush();
You would then read the response out like this.
var response:String = mySocket.readUTFBytes(mySocket.bytesAvailable);