Opened 8 years ago
Closed 5 years ago
#643 closed defect (fixed)
Streaming RST handling
| Reported by: | zzz | Owned by: | |
|---|---|---|---|
| Priority: | minor | Milestone: | 0.9.19 |
| Component: | streaming | Version: | 0.9 |
| Keywords: | Cc: | ||
| Parent Tickets: | Sensitive: | no |
Description
When a RST is received as a response to opening a new connection (for example due to connection limits at the server), it does not propagate well. The HTTP client proxy displays the standard 'eepsite unreachable' page. In other places (eepget?) the client may retry repeatedly. Retries just bust the conn limits further.
Review and improve the way that RSTs are handled and propagated through the protocol stack. Create a new error page for the HTTP proxy for 'connection reset by peer'. 5xx error code? 503, 598, 599? What does privoxy do? http://en.wikipedia.org/wiki/List_of_HTTP_status_codes
Subtickets
Change History (3)
comment:1 Changed 7 years ago by
| Milestone: | 0.9.3 |
|---|
comment:2 Changed 5 years ago by
comment:3 Changed 5 years ago by
| Milestone: | → 0.9.19 |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
#788 made it easy. New error pages return 403. In 93f405d6dcaf1188e535fde30f73d25b856a6335 0.9.18-11-rc.
Note: See
TracTickets for help on using
tickets.
Brought up again at http://zzz.i2p/topics/1849
Some of the work done for ticket #788 can be leveraged here. Throw an I2PSocketException with a unique status code (let's start streaming ones at 512 to not overlap with router- or client-side I2CP), check for it in i2ptunnel HTTP client.