Skip to content

fix pos substrings #1

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

Merged
merged 1 commit into from
Oct 13, 2018
Merged

fix pos substrings #1

merged 1 commit into from
Oct 13, 2018

Conversation

reloxx13
Copy link

key_end_pos--;
dont count down here, it will cut of every key by -1 ("save" will be "sav") (substring (end = up to, but not including, so no need to -1)

Parsing cpp L329
arg.value = urlDecode(data.substring(equal_index + 1, next_index - 1));
=> -1 is too less for substring (substring (end = up to, but not including, so no need to -1)

key_end_pos--;
dont count down here, it will cut of every key by -1 ("save" will be "sav") (substring  (end = up to, but not including, so no need to -1)

Parsing cpp L329
arg.value = urlDecode(data.substring(equal_index + 1, next_index - 1));
=> -1 is too less for substring (substring  (end = up to, but not including, so no need to -1)
@d-a-v d-a-v merged commit 8be9539 into d-a-v:parserequest Oct 13, 2018
@d-a-v
Copy link
Owner

d-a-v commented Oct 13, 2018

Thanks!
I had been only testing this code under linux, I guess my test setup was wrong,
because this code was indeed not working in esp.
Will push it soon to upstream with a proper "plain={body}" fix for alexa

d-a-v pushed a commit that referenced this pull request Jan 5, 2019
* DNSServer: Handle examplewww.com correctly

Just replacing 'www.' with the empty string when we assign the
domainname will remove all occurrences of 'www.', not just those
at the start of the string.

Change this to a startsWith check so that only "www." at the
beginning of the string is removed.

* DNSServer: Rework request handling

Rewrite the request handling in the DNSServer code to address the
following issues:

Compatibility with EDNS #1:

   RFC6891 says that
     "Responders that choose not to implement the protocol
      extensions defined in this document MUST respond with a
      return code (RCODE) of FORMERR to messages containing an
      OPT record in the additional section and MUST NOT include an
      OPT record in the response"

   If we have any additional records in the request, then we need
   to return a FORMERR, and not whatever custom error code the user
   may have set.

Compatibility with EDNS #2:

   If we're returning an error, we need to explicitly zero all of
   the record counters. In the existing code, if there is an
   additional record present in the request, we return an ARCOUNT
   of 1 in the response, despite including no additional records
   in the payload.

Don't answer non-A requests

   If we receive an AAAA request (or any other non-A record)
   requests, we shouldn't respond to it with an A record.

Don't answer non-IN requests

   If we receive a request for a non-IN type, don't answer it
   (it's unlikely that we'd see this in the real world)

Don't read off the end of malformed packets

   If a packet claims to have a query, but then doesn't include
   one, or includes a query with malformed labels, don't read off
   the end of the allocated data structure.

* DNSServer: Clarify and tidy writing the answer record

Modify the code used to write the answer record back to the server
so that it is clearer that we are writing network byte order
16-bit quantities, and to clarify what's happening with the pointer
used at the start of the answer.
d-a-v pushed a commit that referenced this pull request Feb 19, 2021
agruminolemon board definition fixes
d-a-v pushed a commit that referenced this pull request Apr 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants