View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002251 | GNUnet | GNS | public | 2012-04-02 13:09 | 2013-08-15 14:44 |
| Reporter | schanzen | Assigned To | Christian Grothoff | ||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | won't fix | ||
| Product Version | Git master | ||||
| Target Version | Git master | Fixed in Version | Git master | ||
| Summary | 0002251: Reverse proxy for GNS enabled web pages | ||||
| Description | By implementing a reverse proxy it is possible to write web pages that can identify GNS requests and modify links accordingly. Example: Client is GNS enabled and requests a webpage from a GNS reverse proxy enabled server -> server will translate all links that he knows a LEHO for (example.com) to relative GNS links (example.+). The GNS enabled client (proxy) will then translate this link to example.webserver.gnunet. In case the client is not GNS enabled the LEHO will not be replaced. To determine the clients GNS support a HTTP header could be added. Like GNS-Version: x.x or GNS: enabled Benefits: The transition from DNS to GNS is transparent to the user. Drawbacks: 1. If a host has a LEHO (example.webserver.gnunet -> example.com) the client proxy will (atm) translate the GNS link back to the LEHO for SSL validation/requests (not the links on the page!). Maybe make this configurable in the proxy? This does not directly affect the reverse proxy because the identification happens via header. 2. The reverse LEHO translation (server side) must happen only via namestore (so no "regular" DHT enabled lookup). This functionality is not yet supported by GNS api. | ||||
| Tags | No tags attached. | ||||
|
|
Ad 2. This is implemented in the GNS API as a use_cache=GNUNET_YES flag in the lookup call; |
|
|
Ad 1. I don't see this as a problem actually. The LEHO is used to specify a name that is given in a certificate. It is VERY unlikely we would get a .gnunet certificate. And if so.. we shouldn't have a LEHO in the first place because the server in question is GNS "aware" |
|
|
I'm starting to think this will be way too complicated, even for the medium term. Even the forward-proxy is likely too complex with the URI rewriting (should be done in the browser). So think this one should be closed as 'won't fix'. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-04-02 13:09 | schanzen | New Issue | |
| 2012-04-02 13:09 | schanzen | Status | new => assigned |
| 2012-04-02 13:09 | schanzen | Assigned To | => schanzen |
| 2012-05-03 01:21 | Christian Grothoff | Product Version | => Git master |
| 2012-05-03 01:21 | Christian Grothoff | Target Version | => 0.9.4 |
| 2012-06-13 20:32 | Christian Grothoff | Target Version | 0.9.4 => 0.9.5 |
| 2012-06-18 23:33 | schanzen | Note Added: 0006098 | |
| 2012-06-18 23:36 | schanzen | Note Added: 0006100 | |
| 2012-08-28 11:48 | Christian Grothoff | Priority | normal => high |
| 2012-10-07 14:05 | Christian Grothoff | Target Version | 0.9.5 => |
| 2012-10-07 14:17 | Christian Grothoff | Target Version | => 0.10.1 |
| 2013-07-10 23:43 | Christian Grothoff | Priority | high => low |
| 2013-07-10 23:43 | Christian Grothoff | Target Version | 0.10.1 => |
| 2013-07-10 23:43 | Christian Grothoff | Assigned To | schanzen => |
| 2013-07-10 23:43 | Christian Grothoff | Status | assigned => confirmed |
| 2013-08-15 14:44 | Christian Grothoff | Note Added: 0007381 | |
| 2013-08-15 14:44 | Christian Grothoff | Assigned To | => Christian Grothoff |
| 2013-08-15 14:44 | Christian Grothoff | Reproducibility | have not tried => N/A |
| 2013-08-15 14:44 | Christian Grothoff | Status | confirmed => closed |
| 2013-08-15 14:44 | Christian Grothoff | Resolution | open => won't fix |
| 2013-08-15 14:44 | Christian Grothoff | Fixed in Version | => Git master |
| 2013-08-15 14:44 | Christian Grothoff | Target Version | => Git master |
