-
-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix/compliant writable gw #1917
Conversation
There is a bit of a mismatch between the assumptions of the HTTP methods and our assumption of content-addressed and immutable paths. However, the RFC text on The usual assumption about On the other hand, perhaps we could read the RFC liberally and interpret “The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics” with the assumption that given an existing This would certainly be much nicer for everyone than having to handle a special |
70b14ec
to
3c3683a
Compare
3c3683a
to
385749e
Compare
Note to self: keep an eye on ipfs/infra#105 for relevant parts. |
Was this waiting on input from me? |
@jbenet no, sorry. I'll try to get this done this week. |
aa7b637
to
120f500
Compare
rebased, tests still broken. |
eb204f6
to
b342035
Compare
Tests should be fixed now. RFCR. |
Forgot about the sharness tests - can't run them on my bsd office box right now, fill fix them later at home |
return | ||
case "PUT": | ||
i.putHandler(w, r) | ||
// TODO(cryptix): where are the docs? | ||
http.Error(w, "writableGateway: PUT method not meaningful on IPFS - use POST and see the docs", http.StatusMethodNotAllowed) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can just remove the PUT-case and let it fall through to the method error in lines 81 ff.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
m) thanks! :)
From ipfs/infra#105
Just unconditionally have the gateway not pin -- we can add an option for implicit pinning later (I don't think we need it). |
105aeb7
to
7d45f21
Compare
Thanks for that insight and the review! |
daemon failed to startup really often for me, increased pollEndpoint timeout. (updates #1917) also fixes a small printf bug in pollEndpoint. License: MIT Signed-off-by: Henry <cryptix@riseup.net>
ok sgtm |
could other people CR this too? |
#1886 (comment) License: MIT Signed-off-by: Henry <cryptix@riseup.net>
ede0559
to
0b202cd
Compare
rebased and now apparently broken.. not sure what changed under this. |
:( -- |
just looks like your code is returning 405's for a bunch of things... |
I know - it passed the last time I worked on it before the rebase. Need to take a log of the source subtree and see what was introduce. Sent from my iPhone
|
@cryptix do you have time to take another look at this? |
Actually, Yup. I fear the rebase, though. I might need to nag somebody but will try.
|
@whyrusleeping I tried but I have no idea what is going on with the code changes. Hope somebody else can pick this up. |
This is follow up to #1886
(and might have some commits from it until it is merged)rebased.@ion1 made a fair point here about POST being a better choice for the
ipfs object patch
functionality of the writable gateway. I whipped up some tests for these cases.My main open question: How do we want to specify the name to overwrite in the
POST /ipfs/QmFoo/...
case? I don't like to involve theContent-Disposition: …; filename="…"
header. Can't we just use the last part of the request path as that? Also feels like a pain to get right for users.