Rack::Lint::LintError: Status must be >=100 seen as integer about rack HOT 10 CLOSED

Make we should change Lint so that it doesn't check for response status if full hijack has been done?

from rack.

I looked back thru Puma, and a commit Add support for async socket handoff (08-Jan-2012) checked whether status == -1.

WebSocket was finalized first in Dec-2011 with "IETF 6455 The WebSocket Protocol".

from rack.

I guess I'm OK for -1 as status if full hijack is active.

from rack.

Is there a reason you think this is a bug in Rack? If you are just asking for general help, you could post in Discussions, but the problem you are having does not appear related to Rack itself. It's probably an issue in ActionCable.

from rack.

Is there a reason you think this is a bug in Rack? If you are just asking for general help, you could post in Discussions, but the problem you are having does not appear related to Rack itself. It's probably an issue in ActionCable.

OK I wasn't sure but if it's not a Rack issue, I'll look elsewhere. Thanks.

from rack.

@lacostenycoder IIUC, your question is, why does the lint reject status=-1?

I suppose in the past, -1 was used to indicate "ignore this response" and was used when performing a full hijack. @jeremyevans not sure if we document it, but what should the user return when performing a full hijack?

from rack.

According to https://github.com/rack/rack/blob/main/SPEC.rdoc#full-hijack- the response is ignored, so in theory you can return any valid status code, e.g. 200 okay, etc.

@jeremyevans should we consider allowing -1? or nil? I think the reason not to do this is because other middleware may not be aware of the full hijack. AFAIK, there is no mechanism to signal on the return path that the response is to be ignored.

from rack.

The problem with this, is that all middleware needs to accommodate it on the return path. I think it would be better to document a standard for full hijack - either -1 is acceptable as a status code and indicates the response is invalid, or something else? I suppose -1 was chosen since it still compares correctly.

from rack.

So is this a case where perhaps this issue can be resolved in this repo? Because for now I used this monkey patch eek.

from rack.

Please open a PR with the following changes:

• Explicitly document the response that should be returned when using full hijack.
• Let's add some tests and fix Rack::Lint to accept that.

from rack.