[ruby-core:69604] [Ruby trunk - Feature #11266] [Open] WEBrick: allow subclassing of Response and Request

[ruby-core:69604] [Ruby trunk - Feature #11266] [Open] WEBrick: allow subclassing of Response and Request

[me]

Issue #11266 has been reported by Julik Tarkhanov.

----------------------------------------
Feature #11266: WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266

* Author: Julik Tarkhanov
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.




-- 
https://bugs.ruby-lang.org/

[ruby-core:69607] [Ruby trunk - Feature #11266] WEBrick: allow subclassing of Response and Request

[me]

Issue #11266 has been updated by Julik Tarkhanov.

File custom_req_response.patch added

Patch against current trunk, should be backportable.

----------------------------------------
Feature #11266: WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266#change-52950

* Author: Julik Tarkhanov
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.


---Files--------------------------------
custom_req_response.patch (3.25 KB)


-- 
https://bugs.ruby-lang.org/

[ruby-core:69608] [Ruby trunk - Feature #11266] [PATCH] WEBrick: allow subclassing of Response and Request

[me]

Issue #11266 has been updated by Julik Tarkhanov.

Subject changed from WEBrick: allow subclassing of Response and Request to [PATCH] WEBrick: allow subclassing of Response and Request

----------------------------------------
Feature #11266: [PATCH] WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266#change-52951

* Author: Julik Tarkhanov
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.


---Files--------------------------------
custom_req_response.patch (3.25 KB)


-- 
https://bugs.ruby-lang.org/

[ruby-core:69624] [Ruby trunk - Feature #11266] [PATCH] WEBrick: allow subclassing of Response and Request

[nobu]

Issue #11266 has been updated by Nobuyoshi Nakada.


Any reason to create both together in `create_request_and_response`?

----------------------------------------
Feature #11266: [PATCH] WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266#change-52969

* Author: Julik Tarkhanov
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.


---Files--------------------------------
custom_req_response.patch (3.25 KB)


-- 
https://bugs.ruby-lang.org/

[ruby-core:69635] [Ruby trunk - Feature #11266] [PATCH] WEBrick: allow subclassing of Response and Request

[me]

Issue #11266 has been updated by Julik Tarkhanov.


No specific reason, only to make the changes to the library smaller. They certainly can be separate methods.

----------------------------------------
Feature #11266: [PATCH] WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266#change-52989

* Author: Julik Tarkhanov
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.


---Files--------------------------------
custom_req_response.patch (3.25 KB)


-- 
https://bugs.ruby-lang.org/

[ruby-core:69679] [Ruby trunk - Feature #11266] [PATCH] WEBrick: allow subclassing of Response and Request

[me]

Issue #11266 has been updated by Julik Tarkhanov.

File req_response_sub2.patch added

Version with separate methods

----------------------------------------
Feature #11266: [PATCH] WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266#change-53048

* Author: Julik Tarkhanov
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.


---Files--------------------------------
custom_req_response.patch (3.25 KB)
req_response_sub2.patch (2.54 KB)


-- 
https://bugs.ruby-lang.org/

[ruby-core:69944] [Ruby trunk - Feature #11266] [PATCH] WEBrick: allow subclassing of Response and Request

[me]

Issue #11266 has been updated by Julik Tarkhanov.


Nobu, is there something else I can do?

----------------------------------------
Feature #11266: [PATCH] WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266#change-53371

* Author: Julik Tarkhanov
* Status: Open
* Priority: Normal
* Assignee: 
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.


---Files--------------------------------
custom_req_response.patch (3.25 KB)
req_response_sub2.patch (2.54 KB)


-- 
https://bugs.ruby-lang.org/

[ruby-core:69945] [Ruby trunk - Feature #11266] [Assigned] [PATCH] WEBrick: allow subclassing of Response and Request

[nobu]

Issue #11266 has been updated by Nobuyoshi Nakada.

Status changed from Open to Assigned
Assignee set to Hiroshi Nakamura

----------------------------------------
Feature #11266: [PATCH] WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266#change-53372

* Author: Julik Tarkhanov
* Status: Assigned
* Priority: Normal
* Assignee: Hiroshi Nakamura
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.


---Files--------------------------------
custom_req_response.patch (3.25 KB)
req_response_sub2.patch (2.54 KB)


-- 
https://bugs.ruby-lang.org/

[ruby-core:70249] [Ruby trunk - Feature #11266] [PATCH] WEBrick: allow subclassing of Response and Request

[me]

Issue #11266 has been updated by Julik Tarkhanov.


Is there still anything I can do/change?

----------------------------------------
Feature #11266: [PATCH] WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266#change-53672

* Author: Julik Tarkhanov
* Status: Assigned
* Priority: Normal
* Assignee: Hiroshi Nakamura
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.


---Files--------------------------------
custom_req_response.patch (3.25 KB)
req_response_sub2.patch (2.54 KB)


-- 
https://bugs.ruby-lang.org/

[ruby-core:76121] [Ruby trunk Feature#11266] [PATCH] WEBrick: allow subclassing of Response and Request

[me]

Issue #11266 has been updated by Julik Tarkhanov.


It has been a year. Is there still anything I can do/change?

----------------------------------------
Feature #11266: [PATCH] WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266#change-59325

* Author: Julik Tarkhanov
* Status: Assigned
* Priority: Normal
* Assignee: Hiroshi Nakamura
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.


---Files--------------------------------
custom_req_response.patch (3.25 KB)
req_response_sub2.patch (2.54 KB)


-- 
https://bugs.ruby-lang.org/

[ruby-core:76212] [Ruby trunk Feature#11266] [PATCH] WEBrick: allow subclassing of Response and Request

[naruse]

Issue #11266 has been updated by Yui NARUSE.

Assignee changed from Hiroshi Nakamura to webrick

----------------------------------------
Feature #11266: [PATCH] WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266#change-59428

* Author: Julik Tarkhanov
* Status: Assigned
* Priority: Normal
* Assignee: webrick
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.


---Files--------------------------------
custom_req_response.patch (3.25 KB)
req_response_sub2.patch (2.54 KB)


-- 
https://bugs.ruby-lang.org/

[ruby-core:76575] [Ruby trunk Feature#11266] [PATCH] WEBrick: allow subclassing of Response and Request

[rr.rosas]

Issue #11266 has been updated by Rodrigo Rosenfeld Rosas.


+1 Since WEBrick is part of stdlib, being able to use it in a generic test server which supported Rack hijack would be great as such requests could be tested without any sort of mocking.

----------------------------------------
Feature #11266: [PATCH] WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266#change-59801

* Author: Julik Tarkhanov
* Status: Assigned
* Priority: Normal
* Assignee: webrick
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.


---Files--------------------------------
custom_req_response.patch (3.25 KB)
req_response_sub2.patch (2.54 KB)


-- 
https://bugs.ruby-lang.org/

[ruby-core:89910] [Ruby trunk Feature#11266] [PATCH] WEBrick: allow subclassing of Response and Request

[me]

Issue #11266 has been updated by julik (Julik Tarkhanov).


It has been... a very long time. Nobu, is there something else I can do?

----------------------------------------
Feature #11266: [PATCH] WEBrick: allow subclassing of Response and Request
https://bugs.ruby-lang.org/issues/11266#change-74992

* Author: julik (Julik Tarkhanov)
* Status: Assigned
* Priority: Normal
* Assignee: webrick
* Target version: 
----------------------------------------
To properly support the Rack specification features introduced in 2013, a number of features is needed in HTTPResponse.

* The Response should be able to handle it's socket to the given proc for writing (the socket control should be transferred to another routine). This is required for rack.hijack to work.
* The Response assumes an "IO pull" model via read()/readpartial() for grabbing data from the body. Rack assumes a "push" model for writing the response, so having the ability to take over the socket is better for Rack as well. We can make a Fiber-based adapter to let an iterable object present itself like an IO to WEBrick but having direct socket control is much easier.
* The Response should be able to take control of the chunking. This is currently done as a monkeypatch in Rack, but we much rather have it contained in the Response objects used by the Rack-supplied server handler.

Rack currently solves it by giving WEBrick the read end of an IO pipe, which has a side effect of buffering the entire response even when direct socket operation is needed. This creates a situation where no Rack-based streaming servers can function (no long-polling, no server-sent-events, no large streamed responses via HTTP/FTP adapters etc.)

Since all the three of those require patches to the HTTPResponse, a better approach would be to let the Server object create the right Response and let that response deal with the socket in a way it sees fit. This, however, is impossible at the moment because HTTPResponse and HTTPRequest are hardcoded in the main Server loop code, so if you want to override them with your implementations you have to override the entire service() method.

If we let the Server object instantiate the Response and Request in it's own separate method a Server subclass could use customized versions of those. Pretty much the only downside is one extra method call per HTTP request. Rack could then use it's own Server subclass with the right Response and Request objects in place.

I will be happy to provide a patch.


---Files--------------------------------
custom_req_response.patch (3.25 KB)
req_response_sub2.patch (2.54 KB)


-- 
https://bugs.ruby-lang.org/

[ruby-core:90621] Re: [Ruby trunk Feature#11266] [PATCH] WEBrick: allow subclassing of Response and Request

[Eric Wong]

me@julik.nl wrote:
> It has been... a very long time. Nobu, is there something else I can do?
>
> https://bugs.ruby-lang.org/issues/11266#change-74992

Committed as r66452.  Sorry for the delays, I wasn't webrick
maintainer at the time this was brought up so I missed it.

In the future, ping us every week or so to get more people to notice
it. And feel free to Cc: me on webrick or any changes I've been
responsible for in the past.  Thanks.