net/http/status.rb has been added (#12935) but it is not required from net/http.rb while other net/http/*.rb files are already required.
Is this intentional?
I think it would make sense, given how important http status codes
are in general (and people who use net/http may also usually deal
with http status codes).
I think it would make sense, given how important http status codes
are in general (and people who use net/http may also usually deal
with http status codes).
I disagree, nothing in net/http client code relies on status
code messages. Loading status messages would needlessly
increase the memory footprint of people who only want an
HTTP client.
Having a code number -> message mapping is useful to servers
(but unfortunately having require "net/http" in
net/http/status would needlessly bloat servers, too).
net/http itself doesn't need net/http/status.
Therefore at this time it's intentional.
Though I may change it if there's a reasonable use case to require it.
IMHO, I would suggest use Kernel::autoload, thus we don't need to type net/http/status when we want it, and they will never be loaded into memory until we try to access the constant STATUS_CODES. Isn't it win-win?
IMHO, I would suggest use Kernel::autoload, thus we don't need to type net/http/status when we want it, and they will never be loaded into memory until we try to access the constant STATUS_CODES. Isn't it win-win?
No, it's a trade-off, and a bad trade-off in my opinion. See #5653. Even if the particular implementation issues with autoload are or have been addressed, my main problem with autoload is that libraries that use it are a pain to use in security sensitive code that uses Dir.chroot. Well designed libraries should require all files at load/application startup time, and avoid requiring files during application runtime, and autoload is a hidden runtime require.
IMHO, I would suggest use Kernel::autoload, thus we don't need to type net/http/status when we want it, and they will never be loaded into memory until we try to access the constant STATUS_CODES. Isn't it win-win?
No, it's a trade-off, and a bad trade-off in my opinion. See #5653. Even if the particular implementation issues with autoload are or have been addressed, my main problem with autoload is that libraries that use it are a pain to use in security sensitive code that uses Dir.chroot. Well designed libraries should require all files at load/application startup time, and avoid requiring files during application runtime, and autoload is a hidden runtime require.
Hi Jeremy, thank you for the reference, I didn't know that thread before (It seems like there has not been a conclusion yet :(
Updated by 
Updated by 
Updated by 
Updated by 
Updated by 
Updated by