[SERVER-27318] Network layer should reject OP_COMMAND requests where "command name" wire protocol field doesn't match first element of command request object Created: 07/Dec/16 Updated: 06/Dec/22 Resolved: 22/Dec/16 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Networking |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | J Rassi | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Query
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Participants: | |||||||||
| Description |
|
According to discussion at https://groups.google.com/forum/#!topic/mongodb-dev/tJMdvcpGq6Y, it seems as if the server dispatches OP_COMMAND requests based on the wire protocol "command name" field, but the network layer never verifies that the "command name" field matches the first element of the command request. This can yield confusing error messages in command execution (as exhibited by the thread above), and can possibly trip an assertion if any command implementations assert that the first field of the command request object is the expected command name. |
| Comments |
| Comment by Spencer Jackson [ 22/Dec/16 ] |
|
I believe this ticket is a duplicate of I constructed a OP_COMMAND request per the linked discussion and executed it against a mongod built off of master. This returned the error message, "Command name parsed in OP_COMMAND message 'find' doesn't match command name from object 'filter'". This error message was introduced in |