Silverlight Proxy Page: proxy.ashx

[SimonLiu]

Hi

I was recently comparing the Silverlight proxy page to the JavaScript API's equivalent.

The Silverlight proxy.ashx has a more recent timestamp and more functionality, so I assumed the JavaScript proxy page was out-of-date.

Two (hopefully quick) questions:

1) Can I use the Silverlight proxy page as a drop-in replacement for the JavaScript API's proxy page, or are they deliberately kept separate?

2) The Silverlight proxy.ashx forces the Content-Type of the response sent back to the client to be application/x-www-form-urlencoded, but the JavaScript proxy.ashx does not. Is there a reason for this?

Thanks for any responses. 🙂

[RexHansen]

The proxy page included with the Silverlight API is a streamlined/enhanced version of the one included with the JavaScript API.  Basically generating the request and processing the response have been streamlined for the Web APIs.  Plus the proxy included with the Silverlight API supports secured services using tokens (long and short term) and http/windows authentication.  The JavaScript API proxy only supports long term tokens. 

1) Yes.  As far as redirecting requests is concerned, the proxies are basically the same.
2) The Silverlight API proxy sets the content type of the request (if a POST) to "application/x-www-form-urlencoded" because its only been designed to support the use of a proxy (e.g. ProxyUrl) within the Web APIs.   Since POSTed requests from the Web API to the proxy always contain text, this content type will work.  However if you wanted to use the proxy to upload a file, you'd probably want to go with multipart/form-data.  Of course you can try to set it on the fly like in the JavaScript API.   Keep in mind you can modify the proxy at will; it only provides a workable starting point to support the use of a proxy in the Web APIs. 

Ideally at some point in the future the proxies will be synchronized.

[SimonLiu]

2) The Silverlight proxy.ashx forces the Content-Type of the response sent back to the client to be application/x-www-form-urlencoded

Oops, I meant to say "the response sent from the proxy to the server", not "the response sent back to the client".

Many thanks for your reply Rex, it was very informative and helped clear up some confusion in my mind.

However, I was wondering about this part of your answer:

Since POSTed requests from the Web API to the proxy always contain text, this content type will work.

I don't think this is always true, because all three web APIs support adding file attachments to feature services on ArcGIS Server 10 (for example, see the Silverlight AttachmentEditor)

If the feature service were locked down and required a proxy page to access it, then file uploads would fail because the Silverlight proxy page doesn't set the content type dynamically at the moment.

Obviously this is a trivial thing to fix, but since the other two APIs' proxy pages already set content types on the fly rather than hard-coding it, could this be changed in the Silverlight proxy page as well?

Many thanks
Simon

[FengLin]

Since POSTed requests from the Web API to the proxy always contain text, this content type will work.  However if you wanted to use the proxy to upload a file, you'd probably want to go with multipart/form-data. 

I need to use the proxy to upload a file, and to go with multipart/form-data, what can I do? Could you give me some code?