[
https://issues.apache.org/jira/browse/SHINDIG-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163128#comment-13163128
]
[email protected] commented on SHINDIG-1667:
--------------------------------------------------------
bq. On 2011-12-05 19:15:25, Brian Lillie wrote:
bq. > In doFetchConcatResources, if one of the 2nd through nth requests
encounters an error such that false would be returned, we still have the
content from the 1st up to the failing request in the
VerbatimConcatOutputStream, and when we do the close on that stream, it will be
written out as well as the the 400 error code. Seems like the cases where
that might occur are probably remote, and having extra data in the response
shouldn't matter. Not sure that it needs to be fixed .. just pointing it out.
Yeah I thought of that too Brian. I think setting the error code when we
return should let be an indication to ignore the content in the response.
Jesse would you agree?
- Ryan
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/3006/#review3628
-----------------------------------------------------------
On 2011-12-04 21:04:16, Ryan Baxter wrote:
bq.
bq. -----------------------------------------------------------
bq. This is an automatically generated e-mail. To reply, visit:
bq. https://reviews.apache.org/r/3006/
bq. -----------------------------------------------------------
bq.
bq. (Updated 2011-12-04 21:04:16)
bq.
bq.
bq. Review request for shindig, Jesse Ciancetta and Brian Lillie.
bq.
bq.
bq. Summary
bq. -------
bq.
bq. After we return from doFetchConcatResources(..) we set the status in
doGet. So lets say we return false from doFetchConcatResources and the content
written to the response was bigger than the buffer. This means we will flush
the buffer and set the status to the OK status then write the rest of the
content and set the status to bad request, but it will be to late we already
set the status to OK
bq.
bq.
bq. This addresses bug SHINDIG-1667.
bq. https://issues.apache.org/jira/browse/SHINDIG-1667
bq.
bq.
bq. Diffs
bq. -----
bq.
bq.
http://svn.apache.org/repos/asf/shindig/trunk/java/gadgets/src/main/java/org/apache/shindig/gadgets/servlet/ConcatProxyServlet.java
1210178
bq.
bq. Diff: https://reviews.apache.org/r/3006/diff
bq.
bq.
bq. Testing
bq. -------
bq.
bq. Ran unit tests and rendered gadgets in common container
bq.
bq.
bq. Thanks,
bq.
bq. Ryan
bq.
bq.
> ConcatProxyServlet sets the HTTP response status after writing the response
> ---------------------------------------------------------------------------
>
> Key: SHINDIG-1667
> URL: https://issues.apache.org/jira/browse/SHINDIG-1667
> Project: Shindig
> Issue Type: Bug
> Affects Versions: 3.0.0
> Reporter: Ryan Baxter
> Priority: Minor
> Fix For: 3.0.0
>
> Attachments: fix-1667.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> After we return from doFetchConcatResources(..) we set the status in doGet.
> So lets say we return false from doFetchConcatResources and the content
> written to the response was bigger than the buffer. This means we will flush
> the buffer and set the status to the OK status then write the rest of the
> content and set the status to bad request, but it will be to late we already
> set the status to OK
--
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
