Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

look at returning responses #236

Closed
GoogleCodeExporter opened this issue Mar 25, 2015 · 2 comments
Closed

look at returning responses #236

GoogleCodeExporter opened this issue Mar 25, 2015 · 2 comments

Comments

@GoogleCodeExporter
Copy link

It's kind of weird that there are currently three potential ways of
returning a response: 
1) return it from #responseForContext:/#handleRequest:
2) signal a WAResponseNotification
3) store it in WARequestContext's response instvar (this instvar is not
current accessed anywhere but the response is stored there)

We should ideally only be using one? Can we remove the instvar?

The response *stream* needs to be passed in the request context when using
a streaming server but this could be a separate subclass of
WARequestContext for streaming servers. This would actually be cleaner
because the request contexts could implement #newResponse or something so
that you would get a StreamingResponse instead of a Response for a
streaming server. Currently, WASessionContinuation>>newResponse has to
check whether #responseStream is nil.


Original issue reported on code.google.com by jfitz...@gmail.com on 9 Nov 2008 at 8:10

@GoogleCodeExporter
Copy link
Author

Original comment by jfitz...@gmail.com on 14 Jan 2009 at 10:50

  • Changed state: Started
  • Added labels: ****
  • Removed labels: ****

@GoogleCodeExporter
Copy link
Author

This is fixed by the Response refactoring. A Response is now stored in the
RequestContext by the ServerAdaptor and RequestHandlers are expected to modify 
that
response. When the request handling finishes or a handler signal a
ResponseNotification, the Response is taken out of the RequestContext and sent 
to the
browser.

Original comment by jfitz...@gmail.com on 31 Jan 2009 at 12:29

  • Changed state: Fixed
  • Added labels: ****
  • Removed labels: ****

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant