Hi all,
Re the resolution below, I request that this be re-opened as I had also raised a similar comment:
> Rxx. Default Use of Runtime Environment Configured Proxy
>
> A conforming specification must specify that by default, widget HTTP
> requests must be made through the proxy server (if any) configured for
> use in HTTP requests issued through the runtime environment or host
> device.
>
> Motivation:
>
> Security, current development practice or industry best-practices, Web
> and offline distribution, interoperability.
>
> Rationale:
>
> To ensure that widgets can be served in environments for which an HTTP
> proxy is required to be used, or be given value-added services
> available only through the HTTP proxy. For example, the runtime
> environment may be pre-configured to offer proxy services for all HTTP
> clients. Unless the widget has special requirements for use of a
> different proxy, the default proxy configuration should be used.
>
To remain silent on the proxy configuration for Widgets raises a serious problem with interoperability. The rationale above describes why. If a particular service environment does not require a proxy, then the host device will likely not be configured to use one. But the existence of that case is not a valid reason to ignore the case in which a proxy *is* required and the host device is configured to use it. In that case, the widget framework must use the proxy by default, or it is likely that web applications will not work.
Putting the burden on the widget developer to “use a proxy if you need one” will not suffice either, because:
- Widget developers will not always know the specific proxy configuration required for each device, and each network which the device can access. Having developers hard code or privately configure proxy settings is not a scalable practice.
- Proxy settings do change for various reasons, and are remotely manageable (e.g. through OMA Device Management in mobile devices). Hard-coded and privately configured proxy settings would be unaffected by these changes.
I request that the section on use of the user-configured and default proxy be restored.
Best regards,
Bryan Sullivan | AT&T
From: Arthur Barstow <[EMAIL PROTECTED]>
Date: Sat, 30 Aug 2008 10:13:17 -0400
Message-Id: <[EMAIL PROTECTED]>
To: Web Applications Working Group WG <[email protected]>
This issue has been closed, based on the WG's agreement on August 26.
Please see the following for details:
<http://www.w3.org/2008/08/26-wam-minutes.html#item03>
-Regards, Art Barstow
On Jun 26, 2008, at 4:18 AM, ext Web Applications Working Group Issue
Tracker wrote:
>
> ISSUE-17: Widgets (not just widget engines) should be able to
> specify which proxies they communicate through
>
> http://www.w3.org/2008/webapps/track/issues/
>
> Raised by: Josh Soref
> On product:
>
> From:
>
> http://lists.w3.org/Archives/Public/public-webapps/2008AprJun/
> 0440.html
>
>> 5:00 PM and as a should, I SHOULD be able to pick a proxy per widget
>> however it shouldn't be a requirement (MUST), because some
>> systems won't
>> want to
>> me: yeah, that adds quite a bit of complexity
>> timeless.bmo1: (not all widgets are created equal, some are more
>> equal than
>> others)
>> me: sounds like a 2.0 feature
>> if someone wants it
>> 5:01 PM timeless.bmo1: the problem is that i can easily have some
>> widgets
>> that i only want to work in some environments
>> and some widgets that will need a proxy at some times
>> yeah stupid corporate firewalls
>> me: yeah, I can already think of use cases
>> timeless.bmo1: however, some things shouldn't work at some times
>> 5:02 PM i have apps like this
>> which may be ip based and don't want them talking to any random
>> server at
>> that ip, but only via some trusted proxy... but i don't want all
>> the other
>> widgets to use that trusted proxy
>> 5:03 PM or in some cases, i really really don't trust the proxy,
>> but it's a
>> necessary evil for a certain widget
>> me: you think it might be something to consider for 1.0 then?
>> timeless.bmo1: sadly yes
