Skip to content
This repository has been archived by the owner on Jan 30, 2020. It is now read-only.

api: check unit name on set operations #869

Merged
merged 1 commit into from
Sep 4, 2014

Conversation

jonboulle
Copy link
Contributor

since we essentially have two fields where the unit name can be set I think it's safest to take this path and ensure they're the same. I also don't feel strongly about the auto-fill so can remove that if you don't like it.

validateName is dumb right now but anticipating #867....

@jonboulle
Copy link
Contributor Author

fixes #862

su.Name = item
}
if item != su.Name {
sendError(rw, http.StatusNotAcceptable, fmt.Errorf("item name %q differs to given unit name %q", item, su.Name))
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess these could do with tests. Maybe in the morning.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, and how about we clarify what "item name" means since it isn't exactly clear to an end-user. How about this: "name in URL %q differs from name in request body %q"

@bcwaldon
Copy link
Contributor

bcwaldon commented Sep 4, 2014

LGTM after error string and testing is addressed

@jonboulle
Copy link
Contributor Author

Updated.

One thing: I'm not entirely convinced either way about status codes (specifically StatusConflict vs. StatusBadRequest). I originally had BadRequest because IMO if it fails this validation it very much is a badly formed request:

The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

.. but ValidateOptions is using StatusConflict, so I changed it for consistency.

Any strong feelings?

@bcwaldon
Copy link
Contributor

bcwaldon commented Sep 4, 2014

They should both be BadRequest

@jonboulle
Copy link
Contributor Author

"both" as in the mismatch and !validateName?

What about !ValidateOptions?

@jonboulle
Copy link
Contributor Author

Doing what I think is best. Changed them all.

@@ -74,11 +85,11 @@ func (ur *unitsResource) set(rw http.ResponseWriter, req *http.Request, item str
if eu == nil {
if len(su.Options) == 0 {
err := errors.New("unit does not exist and options field empty")
sendError(rw, http.StatusConflict, err)
sendError(rw, http.StatusBadRequest, err)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't change this one.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

BadRequest is effectively a syntax error, while Conflict means "I can't do that right now due to some other conditions that you may be able to resolve". In this case, if the unit already existed, the request would have succeeded.

@jonboulle
Copy link
Contributor Author

please give me a ship it, please please

@bcwaldon
Copy link
Contributor

bcwaldon commented Sep 4, 2014

🍧 with squash

@jonboulle
Copy link
Contributor Author

yum!

jonboulle added a commit that referenced this pull request Sep 4, 2014
api: check unit name on set operations
@jonboulle jonboulle merged commit 978dc08 into coreos:master Sep 4, 2014
@jonboulle jonboulle deleted the 862_valid_names branch September 4, 2014 18:45
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants