You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@shindig.apache.org by "Ryan Baxter (Created) (JIRA)" <ji...@apache.org> on 2011/12/06 22:54:40 UTC
[jira] [Created] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Navigating to URLs in the common container has no indication of success or failure
----------------------------------------------------------------------------------
Key: SHINDIG-1669
URL: https://issues.apache.org/jira/browse/SHINDIG-1669
Project: Shindig
Issue Type: Improvement
Affects Versions: 3.0.0
Reporter: Ryan Baxter
When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165235#comment-13165235 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/
-----------------------------------------------------------
(Updated 2011-12-08 15:07:59.683892)
Review request for shindig, Dan Dumont and Stanton Sievers.
Changes
-------
Think my last patch was not using the latest code so I just wanted to make sure the patch was correct.
Summary
-------
When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
This addresses bug SHINDIG-1669.
https://issues.apache.org/jira/browse/SHINDIG-1669
Diffs (updated)
-----
http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211913
http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211913
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211913
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211913
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211913
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211913
Diff: https://reviews.apache.org/r/3037/diff
Testing
-------
Tested in container as well as updating unit tests.
Thanks,
Ryan
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164078#comment-13164078 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
bq. On 2011-12-06 23:03:02, Stanton Sievers wrote:
bq. > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js, line 934
bq. > <https://reviews.apache.org/r/3037/diff/2/?file=62529#file62529line934>
bq. >
bq. > I'd rather be checking for a status of any 2xx code. I'd rather treat redirects and other 3xx codes as failures if they are going to fail at render time anyway.
bq. >
bq. > Also, what is the difference between checking response.error and response.status. Shouldn't they indicate the same thing?
I ignored the 3xx codes because I figured the browser would be able to handle them and redirect the iframe accordingly.
I looked into the response.error case. It looks like that will happen if something goes wrong in the containers proxy. The response.status is the result of actually making the http request.
- Ryan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3681
-----------------------------------------------------------
On 2011-12-06 22:36:38, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-06 22:36:38)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164525#comment-13164525 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3702
-----------------------------------------------------------
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js
<https://reviews.apache.org/r/3037/#comment8270>
Disclaimer: I don't fully understand the impact of case in the jsdoc, however this url: http://code.google.com/closure/compiler/docs/js-for-compiler.html never uses 'String' only 'string'
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js
<https://reviews.apache.org/r/3037/#comment8276>
Please describe the args for the function param: http://code.google.com/closure/compiler/docs/js-for-compiler.html
@param {function(Object)=} does that look right?
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js
<https://reviews.apache.org/r/3037/#comment8279>
Your past review had something like this in it... I thought you changed it to: if(!result[gadgetUrl] || result[gadgetUrl].error)
...
navigateCallback([null, result[gadgetUrl] || {error:result});
Is that not needed anymore?
- Dan
On 2011-12-06 22:36:38, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-06 22:36:38)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165242#comment-13165242 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3739
-----------------------------------------------------------
Sorry for being late to the review -- this is the first chance I've had to really look this over. I have a few concerns with this approach that make me wonder if an alternate approach might be more appropriate -- although the alternate I have in mind has some issues of its own too... I'll list my concerns first and then offer the potential alternate solution.
-- Performance (of course, as others have pointed out) on both the client side and server side. On the client side -- if the server takes a while to process the request (say two seconds) then that means the client has to wait four seconds before they actually see the content. On the server side the server will end up seeing twice the load.
-- Side effects of two calls. I know an HTTP GET for an iframe url should be idempotent, but what if its not? We should at least document that the call gets made twice to be sure callers are aware.
-- Authentication. What if the iframe url requires some sort of authentication? Maybe the iframe url returns a a 401 with a basic auth challenge. Or maybe the url is protected with SSO and the clients browser has a valid SSO cookie to send, but shindig would not. In either of these cases we'd say that the navigate failed (since shindig would not be able to auth) but the client may have been able to auth just fine.
-- There's really no *guarantee* that just because the head request succeeds that the subsequent get will succeed too. It's extremely likely to succeed, but not guaranteed.
-- If we go with this approach I think we should offer some way for the caller to opt-out of the head request in case they need to avoid any of the issues I've raised above.
As an alternative -- it seems to me that an onload listener on the iframe with a caller-configurable-timeout might actually be a more useful way to approach this. I think more often than not we have some well known set amount of time that we're willing to wait for the content of the iframe to load before we just give up and call it a failure -- so I'm wondering if we could just register an onload listener on the iframe and if the onload event hasn't fired within the designated amount of time we consider the navigate as a failure. The issues I see with this approach are:
-- It needs to be tested and proven that onload on the iframe works the way I think it does in all major browsers (which is that it only fires if the iframe loaded successfully).
-- If the iframe fails immediately the user would see the error displayed in the frame until the timeout expired (assuming on timeout we put a nice error message in place of the iframe). Maybe the iframe could be hidden until successful? That could degrade from the experience though too... Not sure what the best approach is here.
If the consensus is that the head method is best I'm fine with it (as long as we add the ability for the caller to opt-out) -- I just wanted to be sure to point out all the issues I see and offer this potential alternative for consideration.
- Jesse
On 2011-12-08 15:07:59, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-08 15:07:59)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211913
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164404#comment-13164404 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
bq. On 2011-12-06 23:03:02, Stanton Sievers wrote:
bq. > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js, line 934
bq. > <https://reviews.apache.org/r/3037/diff/2/?file=62529#file62529line934>
bq. >
bq. > I'd rather be checking for a status of any 2xx code. I'd rather treat redirects and other 3xx codes as failures if they are going to fail at render time anyway.
bq. >
bq. > Also, what is the difference between checking response.error and response.status. Shouldn't they indicate the same thing?
bq.
bq. Ryan Baxter wrote:
bq. I ignored the 3xx codes because I figured the browser would be able to handle them and redirect the iframe accordingly.
bq.
bq. I looked into the response.error case. It looks like that will happen if something goes wrong in the containers proxy. The response.status is the result of actually making the http request.
bq.
bq. Stanton Sievers wrote:
bq. Wouldn't we want to follow any 3xx redirects to ensure that the final content is available?
bq.
bq. Another idea I thought of that might be worth evaluating... what if you proxied the iframe urls through Shindig's proxy servlet and returned an error page from there? Maybe add a query param flag that the proxy servlet can read to know whether to return the original response or an error page. That could at least solve the issue of having several http requests.
bq.
bq. The response.error and response.status stuff makes sense.
I don't think that would work. I don't think the proxy would be able to rewrite all of the content and fix images, css, links, etc... for the page to function properly.
- Dan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3681
-----------------------------------------------------------
On 2011-12-06 22:36:38, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-06 22:36:38)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "Ryan Baxter (Reopened) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Baxter reopened SHINDIG-1669:
----------------------------------
Had to revert the change so reopening this issue.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Fix For: 3.0.0
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166199#comment-13166199 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
bq. On 2011-12-08 15:24:35, Jesse Ciancetta wrote:
bq. > Sorry for being late to the review -- this is the first chance I've had to really look this over. I have a few concerns with this approach that make me wonder if an alternate approach might be more appropriate -- although the alternate I have in mind has some issues of its own too... I'll list my concerns first and then offer the potential alternate solution.
bq. >
bq. > -- Performance (of course, as others have pointed out) on both the client side and server side. On the client side -- if the server takes a while to process the request (say two seconds) then that means the client has to wait four seconds before they actually see the content. On the server side the server will end up seeing twice the load.
bq. >
bq. > -- Side effects of two calls. I know an HTTP GET for an iframe url should be idempotent, but what if its not? We should at least document that the call gets made twice to be sure callers are aware.
bq. >
bq. > -- Authentication. What if the iframe url requires some sort of authentication? Maybe the iframe url returns a a 401 with a basic auth challenge. Or maybe the url is protected with SSO and the clients browser has a valid SSO cookie to send, but shindig would not. In either of these cases we'd say that the navigate failed (since shindig would not be able to auth) but the client may have been able to auth just fine.
bq. >
bq. > -- There's really no *guarantee* that just because the head request succeeds that the subsequent get will succeed too. It's extremely likely to succeed, but not guaranteed.
bq. >
bq. > -- If we go with this approach I think we should offer some way for the caller to opt-out of the head request in case they need to avoid any of the issues I've raised above.
bq. >
bq. > As an alternative -- it seems to me that an onload listener on the iframe with a caller-configurable-timeout might actually be a more useful way to approach this. I think more often than not we have some well known set amount of time that we're willing to wait for the content of the iframe to load before we just give up and call it a failure -- so I'm wondering if we could just register an onload listener on the iframe and if the onload event hasn't fired within the designated amount of time we consider the navigate as a failure. The issues I see with this approach are:
bq. >
bq. > -- It needs to be tested and proven that onload on the iframe works the way I think it does in all major browsers (which is that it only fires if the iframe loaded successfully).
bq. >
bq. > -- If the iframe fails immediately the user would see the error displayed in the frame until the timeout expired (assuming on timeout we put a nice error message in place of the iframe). Maybe the iframe could be hidden until successful? That could degrade from the experience though too... Not sure what the best approach is here.
bq. >
bq. > If the consensus is that the head method is best I'm fine with it (as long as we add the ability for the caller to opt-out) -- I just wanted to be sure to point out all the issues I see and offer this potential alternative for consideration.
bq.
bq. Ryan Baxter wrote:
bq. All great points Jesse.
bq.
bq. I thought of the iframe onload event as well, but when I was thinking about it I was hoping there was an event passed into the onload function which would tell me whether the iframe loaded properly or not, but there wasn't (At least I couldn't find any information on it.). I didn't think about doing it the way you described. I did a quick test and FF does not fire the onload event when the URL cannot load the page, but Chrom and IE8 do, so the approach of a timeout would not work.
bq.
bq. I can certainly make the head request an opt in approach and only make the head request when the called supplies a callback into the navigateUrl call, if not, there is no point in making the head request anyways.
Ah -- ok... I'd seen some people saying onload wouldn't get fired for iframes when the content failed to load but hadn't had a chance to test it out -- too bad it isn't consistent across browsers. With the option to opt-out by not passing the callback I think this looks good.
- Jesse
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3739
-----------------------------------------------------------
On 2011-12-08 17:58:33, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-08 17:58:33)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211913
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164792#comment-13164792 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/
-----------------------------------------------------------
(Updated 2011-12-07 22:35:19.458402)
Review request for shindig, Dan Dumont and Stanton Sievers.
Changes
-------
Updates based on reviews from Dan and Stanton.
Summary
-------
When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
This addresses bug SHINDIG-1669.
https://issues.apache.org/jira/browse/SHINDIG-1669
Diffs (updated)
-----
http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
Diff: https://reviews.apache.org/r/3037/diff
Testing
-------
Tested in container as well as updating unit tests.
Thanks,
Ryan
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13166202#comment-13166202 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3779
-----------------------------------------------------------
Ship it!
LGTM
This is an interesting capability -- its too bad we couldn't find a way to get it done without two requests though.
I did actually have one other thought about an alternative that could work (but again has its own share of drawbacks -- many of which are the same as the head approach) but thought I'd share anyway in case it spurs some thoughts from others too. I was thinking there might be a way to add another proxy to shindig for cases like this -- maybe something like IframeProxyServlet -- so the iframe src would point to shindig-server/iframeProxy?url=http://example.com/theIframeContent.html -- and then on the shindig side it could fetch the content, add a script include for the shindig RPC library and then a script block that would fire a message to the parent container as soon as it's processed. On the parent page you could listen for the RPC call and when fired you'd know the iframe loaded. You could probably even do the same thing for the failure case on the shindig side -- you return a page with a friendly error message saying that the content failed to load and fire the RPC to the parent page with a message letting it know that the iframe failed -- and you could even include any details you needed to as to exactly what failed.
Again -- just throwing out some thoughts here -- there would be plenty of issues with this approach too (besides being much more work) like the iframe domain would be that of shindig instead of the real host, relative links in documents probably wouldn't work unless they were rewritten (which I guess shindig already knows how to do) etc -- but thought it was still worth sharing in case anyone else was interested.
- Jesse
On 2011-12-08 17:58:33, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-08 17:58:33)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211913
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165341#comment-13165341 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
bq. On 2011-12-08 15:24:35, Jesse Ciancetta wrote:
bq. > Sorry for being late to the review -- this is the first chance I've had to really look this over. I have a few concerns with this approach that make me wonder if an alternate approach might be more appropriate -- although the alternate I have in mind has some issues of its own too... I'll list my concerns first and then offer the potential alternate solution.
bq. >
bq. > -- Performance (of course, as others have pointed out) on both the client side and server side. On the client side -- if the server takes a while to process the request (say two seconds) then that means the client has to wait four seconds before they actually see the content. On the server side the server will end up seeing twice the load.
bq. >
bq. > -- Side effects of two calls. I know an HTTP GET for an iframe url should be idempotent, but what if its not? We should at least document that the call gets made twice to be sure callers are aware.
bq. >
bq. > -- Authentication. What if the iframe url requires some sort of authentication? Maybe the iframe url returns a a 401 with a basic auth challenge. Or maybe the url is protected with SSO and the clients browser has a valid SSO cookie to send, but shindig would not. In either of these cases we'd say that the navigate failed (since shindig would not be able to auth) but the client may have been able to auth just fine.
bq. >
bq. > -- There's really no *guarantee* that just because the head request succeeds that the subsequent get will succeed too. It's extremely likely to succeed, but not guaranteed.
bq. >
bq. > -- If we go with this approach I think we should offer some way for the caller to opt-out of the head request in case they need to avoid any of the issues I've raised above.
bq. >
bq. > As an alternative -- it seems to me that an onload listener on the iframe with a caller-configurable-timeout might actually be a more useful way to approach this. I think more often than not we have some well known set amount of time that we're willing to wait for the content of the iframe to load before we just give up and call it a failure -- so I'm wondering if we could just register an onload listener on the iframe and if the onload event hasn't fired within the designated amount of time we consider the navigate as a failure. The issues I see with this approach are:
bq. >
bq. > -- It needs to be tested and proven that onload on the iframe works the way I think it does in all major browsers (which is that it only fires if the iframe loaded successfully).
bq. >
bq. > -- If the iframe fails immediately the user would see the error displayed in the frame until the timeout expired (assuming on timeout we put a nice error message in place of the iframe). Maybe the iframe could be hidden until successful? That could degrade from the experience though too... Not sure what the best approach is here.
bq. >
bq. > If the consensus is that the head method is best I'm fine with it (as long as we add the ability for the caller to opt-out) -- I just wanted to be sure to point out all the issues I see and offer this potential alternative for consideration.
All great points Jesse.
I thought of the iframe onload event as well, but when I was thinking about it I was hoping there was an event passed into the onload function which would tell me whether the iframe loaded properly or not, but there wasn't (At least I couldn't find any information on it.). I didn't think about doing it the way you described. I did a quick test and FF does not fire the onload event when the URL cannot load the page, but Chrom and IE8 do, so the approach of a timeout would not work.
I can certainly make the head request an opt in approach and only make the head request when the called supplies a callback into the navigateUrl call, if not, there is no point in making the head request anyways.
- Ryan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3739
-----------------------------------------------------------
On 2011-12-08 15:07:59, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-08 15:07:59)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211913
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13167539#comment-13167539 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
bq. On 2011-12-09 14:25:51, Jesse Ciancetta wrote:
bq. > LGTM
bq. >
bq. > This is an interesting capability -- its too bad we couldn't find a way to get it done without two requests though.
bq. >
bq. > I did actually have one other thought about an alternative that could work (but again has its own share of drawbacks -- many of which are the same as the head approach) but thought I'd share anyway in case it spurs some thoughts from others too. I was thinking there might be a way to add another proxy to shindig for cases like this -- maybe something like IframeProxyServlet -- so the iframe src would point to shindig-server/iframeProxy?url=http://example.com/theIframeContent.html -- and then on the shindig side it could fetch the content, add a script include for the shindig RPC library and then a script block that would fire a message to the parent container as soon as it's processed. On the parent page you could listen for the RPC call and when fired you'd know the iframe loaded. You could probably even do the same thing for the failure case on the shindig side -- you return a page with a friendly error message saying that the content failed to load and fire the RPC to the parent page with a message letting it know that the iframe failed -- and you could even include any details you needed to as to exactly what failed.
bq. >
bq. > Again -- just throwing out some thoughts here -- there would be plenty of issues with this approach too (besides being much more work) like the iframe domain would be that of shindig instead of the real host, relative links in documents probably wouldn't work unless they were rewritten (which I guess shindig already knows how to do) etc -- but thought it was still worth sharing in case anyone else was interested.
Thanks Jesse. This is def something to consider for a future enhancement.
- Ryan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3779
-----------------------------------------------------------
On 2011-12-08 17:58:33, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-08 17:58:33)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211913
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211913
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13165368#comment-13165368 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/
-----------------------------------------------------------
(Updated 2011-12-08 17:58:33.234403)
Review request for shindig, Dan Dumont and Stanton Sievers.
Changes
-------
Updated based on Jesse's suggestions.
Summary
-------
When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
This addresses bug SHINDIG-1669.
https://issues.apache.org/jira/browse/SHINDIG-1669
Diffs (updated)
-----
http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211913
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211913
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211913
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211913
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211913
http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211913
Diff: https://reviews.apache.org/r/3037/diff
Testing
-------
Tested in container as well as updating unit tests.
Thanks,
Ryan
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164353#comment-13164353 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
bq. On 2011-12-06 23:03:02, Stanton Sievers wrote:
bq. > Overall this seems OK.
bq. >
bq. > Have you looked at the performance impact here using lifecycle logging?
bq. >
bq. > The extra HTTP round trip could be costly, especially none of the HEAD request can be cached and reused by the subsequent GET. Just throwing it out there, how much sense would it make to do a GET instead of a HEAD request to check for page availability? My reasoning here is that at least the browser will have cached the page contents from the initial GET making the subsequent GET more performant. In the error case the HEAD and GET will take approximately the same amount of time to fail.
bq.
bq. Ryan Baxter wrote:
bq. Would the browser actually cache the response of the osapi.http.get? I am sure Shindig would but I am not sure the browser would. The request for the get will be a post to the rpc servlet, the iframe will make a request to the URL, would the browser be smart enough to know those are the same?
No, the browser is not that smart.
bq. On 2011-12-06 23:03:02, Stanton Sievers wrote:
bq. > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js, line 934
bq. > <https://reviews.apache.org/r/3037/diff/2/?file=62529#file62529line934>
bq. >
bq. > I'd rather be checking for a status of any 2xx code. I'd rather treat redirects and other 3xx codes as failures if they are going to fail at render time anyway.
bq. >
bq. > Also, what is the difference between checking response.error and response.status. Shouldn't they indicate the same thing?
bq.
bq. Ryan Baxter wrote:
bq. I ignored the 3xx codes because I figured the browser would be able to handle them and redirect the iframe accordingly.
bq.
bq. I looked into the response.error case. It looks like that will happen if something goes wrong in the containers proxy. The response.status is the result of actually making the http request.
Wouldn't we want to follow any 3xx redirects to ensure that the final content is available?
Another idea I thought of that might be worth evaluating... what if you proxied the iframe urls through Shindig's proxy servlet and returned an error page from there? Maybe add a query param flag that the proxy servlet can read to know whether to return the original response or an error page. That could at least solve the issue of having several http requests.
The response.error and response.status stuff makes sense.
- Stanton
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3681
-----------------------------------------------------------
On 2011-12-06 22:36:38, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-06 22:36:38)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "Ryan Baxter (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Baxter resolved SHINDIG-1669.
----------------------------------
Resolution: Unresolved
This ended up not being a problem for me as we were able to work around it in the container. However I would like to come back to this at a later date to come up with a better solution to the problem in Shindig.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 2.5.0
> Reporter: Ryan Baxter
> Assignee: Ryan Baxter
> Fix For: 2.5.0
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "Ryan Baxter (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Baxter resolved SHINDIG-1669.
----------------------------------
Resolution: Fixed
Fix Version/s: 3.0.0
Committed revision 1213277.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Fix For: 3.0.0
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163996#comment-13163996 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3687
-----------------------------------------------------------
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js
<https://reviews.apache.org/r/3037/#comment8206>
Never mind here, I am confusing navifateUrl with navigateGadget =(
- Henry
On 2011-12-06 22:36:38, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-06 22:36:38)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163990#comment-13163990 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
bq. On 2011-12-06 23:03:02, Stanton Sievers wrote:
bq. > Overall this seems OK.
bq. >
bq. > Have you looked at the performance impact here using lifecycle logging?
bq. >
bq. > The extra HTTP round trip could be costly, especially none of the HEAD request can be cached and reused by the subsequent GET. Just throwing it out there, how much sense would it make to do a GET instead of a HEAD request to check for page availability? My reasoning here is that at least the browser will have cached the page contents from the initial GET making the subsequent GET more performant. In the error case the HEAD and GET will take approximately the same amount of time to fail.
Would the browser actually cache the response of the osapi.http.get? I am sure Shindig would but I am not sure the browser would. The request for the get will be a post to the rpc servlet, the iframe will make a request to the URL, would the browser be smart enough to know those are the same?
- Ryan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3681
-----------------------------------------------------------
On 2011-12-06 22:36:38, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-06 22:36:38)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163989#comment-13163989 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
bq. On 2011-12-06 23:15:05, Henry Saputra wrote:
bq. > I am not too sure about extra http request to check for existence for URL. Can we just check for status code?
Henry, what request would you check the status code of?
- Ryan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3683
-----------------------------------------------------------
On 2011-12-06 22:36:38, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-06 22:36:38)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164784#comment-13164784 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
bq. On 2011-12-07 17:08:05, Dan Dumont wrote:
bq. > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js, line 922
bq. > <https://reviews.apache.org/r/3037/diff/2/?file=62529#file62529line922>
bq. >
bq. > Disclaimer: I don't fully understand the impact of case in the jsdoc, however this url: http://code.google.com/closure/compiler/docs/js-for-compiler.html never uses 'String' only 'string'
Not sure why i did that in the first place :)
bq. On 2011-12-07 17:08:05, Dan Dumont wrote:
bq. > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js, line 924
bq. > <https://reviews.apache.org/r/3037/diff/2/?file=62529#file62529line924>
bq. >
bq. > Please describe the args for the function param: http://code.google.com/closure/compiler/docs/js-for-compiler.html
bq. >
bq. > @param {function(Object)=} does that look right?
LGTM
bq. On 2011-12-07 17:08:05, Dan Dumont wrote:
bq. > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js, line 221
bq. > <https://reviews.apache.org/r/3037/diff/2/?file=62531#file62531line221>
bq. >
bq. > Your past review had something like this in it... I thought you changed it to: if(!result[gadgetUrl] || result[gadgetUrl].error)
bq. > ...
bq. > navigateCallback([null, result[gadgetUrl] || {error:result});
bq. >
bq. > Is that not needed anymore?
Good catch. Different code but needs to have similar error handling :)
- Ryan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3702
-----------------------------------------------------------
On 2011-12-06 22:36:38, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-06 22:36:38)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "Ryan Baxter (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ryan Baxter reassigned SHINDIG-1669:
------------------------------------
Assignee: Ryan Baxter
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 2.5.0
> Reporter: Ryan Baxter
> Assignee: Ryan Baxter
> Fix For: 2.5.0
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164788#comment-13164788 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
bq. On 2011-12-06 23:03:02, Stanton Sievers wrote:
bq. > http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js, line 934
bq. > <https://reviews.apache.org/r/3037/diff/2/?file=62529#file62529line934>
bq. >
bq. > I'd rather be checking for a status of any 2xx code. I'd rather treat redirects and other 3xx codes as failures if they are going to fail at render time anyway.
bq. >
bq. > Also, what is the difference between checking response.error and response.status. Shouldn't they indicate the same thing?
bq.
bq. Ryan Baxter wrote:
bq. I ignored the 3xx codes because I figured the browser would be able to handle them and redirect the iframe accordingly.
bq.
bq. I looked into the response.error case. It looks like that will happen if something goes wrong in the containers proxy. The response.status is the result of actually making the http request.
bq.
bq. Stanton Sievers wrote:
bq. Wouldn't we want to follow any 3xx redirects to ensure that the final content is available?
bq.
bq. Another idea I thought of that might be worth evaluating... what if you proxied the iframe urls through Shindig's proxy servlet and returned an error page from there? Maybe add a query param flag that the proxy servlet can read to know whether to return the original response or an error page. That could at least solve the issue of having several http requests.
bq.
bq. The response.error and response.status stuff makes sense.
bq.
bq. Dan Dumont wrote:
bq. I don't think that would work. I don't think the proxy would be able to rewrite all of the content and fix images, css, links, etc... for the page to function properly.
OK so did some digging in the BasicHttpFetcher. We set the HttpClient to follow redirects by default so we will follow all redirects when making the head request. With that being said I agree we should change the logic so we only render the URL if the status is >= 200 but < 300.
- Ryan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3681
-----------------------------------------------------------
On 2011-12-06 22:36:38, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-06 22:36:38)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "Henry Saputra (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184727#comment-13184727 ]
Henry Saputra commented on SHINDIG-1669:
----------------------------------------
This needs to be reopened due to SHINDIG-1679
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Fix For: 3.0.0
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13164794#comment-13164794 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/
-----------------------------------------------------------
(Updated 2011-12-07 22:41:10.141656)
Review request for shindig, Dan Dumont and Stanton Sievers.
Changes
-------
Fixed some spacing issues.
Summary
-------
When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
This addresses bug SHINDIG-1669.
https://issues.apache.org/jira/browse/SHINDIG-1669
Diffs (updated)
-----
http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211683
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211683
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211683
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211683
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211683
http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211683
Diff: https://reviews.apache.org/r/3037/diff
Testing
-------
Tested in container as well as updating unit tests.
Thanks,
Ryan
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163958#comment-13163958 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3681
-----------------------------------------------------------
Overall this seems OK.
Have you looked at the performance impact here using lifecycle logging?
The extra HTTP round trip could be costly, especially none of the HEAD request can be cached and reused by the subsequent GET. Just throwing it out there, how much sense would it make to do a GET instead of a HEAD request to check for page availability? My reasoning here is that at least the browser will have cached the page contents from the initial GET making the subsequent GET more performant. In the error case the HEAD and GET will take approximately the same amount of time to fail.
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js
<https://reviews.apache.org/r/3037/#comment8194>
I'd rather be checking for a status of any 2xx code. I'd rather treat redirects and other 3xx codes as failures if they are going to fail at render time anyway.
Also, what is the difference between checking response.error and response.status. Shouldn't they indicate the same thing?
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js
<https://reviews.apache.org/r/3037/#comment8195>
Same here for the response status as my previous comment. I'd rather check that it's not a 2xx status.
- Stanton
On 2011-12-06 22:36:38, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-06 22:36:38)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "Paul Lindner (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul Lindner closed SHINDIG-1669.
---------------------------------
part of 2.5.0-beta1 release.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 2.5.0-beta1
> Reporter: Ryan Baxter
> Assignee: Ryan Baxter
> Fix For: 2.5.0-beta1
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163964#comment-13163964 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/#review3683
-----------------------------------------------------------
I am not too sure about extra http request to check for existence for URL. Can we just check for status code?
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js
<https://reviews.apache.org/r/3037/#comment8202>
So here we will have extra HTTP call back to server to check for given URL exist or not?
- Henry
On 2011-12-06 22:36:38, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3037/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-06 22:36:38)
bq.
bq.
bq. Review request for shindig, Dan Dumont and Stanton Sievers.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
bq.
bq. It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
bq.
bq.
bq. This addresses bug SHINDIG-1669.
bq. https://issues.apache.org/jira/browse/SHINDIG-1669
bq.
bq.
bq. Diffs
bq. -----
bq.
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
bq. http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
bq.
bq. Diff: https://reviews.apache.org/r/3037/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Tested in container as well as updating unit tests.
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "Ryan Baxter (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13184966#comment-13184966 ]
Ryan Baxter commented on SHINDIG-1669:
--------------------------------------
Good call Henry. I will do that.
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Fix For: 3.0.0
>
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (SHINDIG-1669) Navigating to URLs in the common
container has no indication of success or failure
Posted by "jiraposter@reviews.apache.org (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/SHINDIG-1669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163936#comment-13163936 ]
jiraposter@reviews.apache.org commented on SHINDIG-1669:
--------------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3037/
-----------------------------------------------------------
Review request for shindig, Dan Dumont and Stanton Sievers.
Summary
-------
When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
This addresses bug SHINDIG-1669.
https://issues.apache.org/jira/browse/SHINDIG-1669
Diffs
-----
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/open-views/viewenhancements-container.js 1211103
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/embeddedexperiences/embedded_experiences_container.js 1211103
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container/container.js 1211103
http://svn.apache.org/repos/asf/shindig/trunk/features/src/main/javascript/features/container.util/util.js 1211103
http://svn.apache.org/repos/asf/shindig/trunk/content/samplecontainer/examples/embeddedexperiences/PhotoList.xml 1211103
http://svn.apache.org/repos/asf/shindig/trunk/features/src/test/javascript/features/container.url/container_url_test.js 1211103
Diff: https://reviews.apache.org/r/3037/diff
Testing
-------
Tested in container as well as updating unit tests.
Thanks,
Ryan
> Navigating to URLs in the common container has no indication of success or failure
> ----------------------------------------------------------------------------------
>
> Key: SHINDIG-1669
> URL: https://issues.apache.org/jira/browse/SHINDIG-1669
> Project: Shindig
> Issue Type: Improvement
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> When you call commoncontainer.navigateUrl if the URL cannot be reached the caller has no way of knowing if the URL was navigated successfully or not. To solve this we make a head request to the URL we are navigating to and add a callback to the API.
> It is important to note that we will not be caching the response of the head request. While this could possibly give us better performance we have no way of guaranteeing the server will still be up next time and everything may fail. This is different from the gadget case where we have the gadget XML cached on the server.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira