https://issues.apache.org/bugzilla/show_bug.cgi?id=56707
Yann Ylavic <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from Yann Ylavic <[email protected]> --- (In reply to Ahab. A. from comment #8) > I tried your work-arounds and unfortunately I was unsuccessful as normal > (non-websocket) HTTP seems to break (not all content gets flushed out). Also > ap_send_interim_response() seems to ignore sending the HTTP status CODE, I > had to work around that by prepending the status code to the status line to > get the status response in proper HTTP form. Yes, my bad, both r->status *and* r->status_line (which means status code + reason in httpd) need to be set before calling ap_send_interim_response(). What do you mean by "not all content gets flushed out"? The 101 response (which is a header only) isn't flushed to the client or does it relate to upcoming (websocket) data? > > In any event, I think the real problem is that Apache's HTTP processing in > general (http module, filters..etc) are not AWARE of the "new" websocket > protocol all together! For example, it doesn't know/aware of HTTP code 101 > "Switching Protocol" nor is it aware of "Connection: upgrade" and "Upgrade: > websocket" headers. mod_proxy_wstunnel is aware of all that, and does the right thing (ie. not using HTTP level filters/functions to handle websocket specifics). > > If you look at Apache's HTTP protocol code, for example, http_protocol.c, > http_filters.c..etc, you'll clearly see it only assume EITHER chunked > encoding or content length (for payload processing). These are the only payload delimiters defined by the HTTP RFC. > Also, it only assumes > the "Connection" header can have either "close or keepalive" values, it's > not aware of "upgrade" value. You can go on and on with examples like that. Again, these are the only Connection header values httpd has to be aware of, the other values are specific and have to be handled by a dedicated module (like mod_proxy_wstunnel does for websockets, you should probably look at the way this is handled there). Anyway, since this is about your module's handling of websockets (unless mod_proxy_wstunnel or ap_send_interim_response() do not work as expected), this should be discussed on the [email protected] list, this report db is for httpd bugs only. I'm closing this PR for now, please reopen only if httpd is misbehaving (in its scope, eg. mod_proxy_wstunnel or ap_send_interim_response). -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
