Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Inbound Parse: All attachments have Content-Type: text/plain #412

Open
garydevenay opened this issue Oct 22, 2020 · 5 comments · May be fixed by #416
Open

Inbound Parse: All attachments have Content-Type: text/plain #412

garydevenay opened this issue Oct 22, 2020 · 5 comments · May be fixed by #416
Labels
status: help wanted requesting help from the community type: community enhancement feature request not on Twilio's roadmap

Comments

@garydevenay
Copy link

garydevenay commented Oct 22, 2020 •
edited

Issue Summary

When receiving an attachment via Inbound Parse and using the helper, the content type of all attachments are text/plain. I have tested this with .zip and .jpg files.

I would expect these to be application/zip (or at least application/octet-stream) and image/jpg

Steps to Reproduce

  1. Send email to your inbound address
  2. Use the below code to spit out the content types of attachments.

Code Snippet

func HandleInbound(w http.ResponseWriter, r *http.Request) {
    parsed := inbound.Parse(r)
    for name, contents := range parsed.Attachments {
        contentType := http.DetectContentType(contents)
        fmt.Printf("%v has content type %v", name, contentType)
    }
}

Exception/Log

test.jpg has content type text/plain; charset=utf-8
test.zip has content type text/plain; charset=utf-8

Technical details:

  • sendgrid-go version: v3.6.4
  • go version: 1.15.1
@eshanholtz
Copy link
Contributor

Hi @garydevenay

I noticed you're using http.DetectContentType(contents) to determine the content type, instead of reading the type parsed from the email by inbound.Parse. Is the content type parsed from the email using the inbound helper correct?

@eshanholtz eshanholtz added status: waiting for feedback waiting for feedback from the submitter type: question question directed at the library labels Oct 24, 2020
@garydevenay
Copy link
Author

Hi @eshanholtz
Thanks for the reply. As I understand contents is a map[string][]byte containing the file contents with the filename as the key (Reference) Is there a separate property of ParsedEmail that contains the content type?

@eshanholtz
Copy link
Contributor

Ah, my apologies. There is a ParsedEmail.Headers property that reads headers from the email, but the Content-Type header you would end up reading from there is multipart/mixed. I was able to recreate your issue using http.DetectContentType on our test email attachments. I think the best path forward here would be to extend the inbound module to give Attachments its own ParsedAttachment struct type, with its own Headers, Filename, and Content properties. The Headers property would be populated based on the data in the emailPart's Header property.

This issue has been added to our internal backlog to be prioritized. Pull requests and +1s on the issue summary will help it move up the backlog.

@eshanholtz eshanholtz added status: help wanted requesting help from the community type: community enhancement feature request not on Twilio's roadmap and removed status: waiting for feedback waiting for feedback from the submitter type: question question directed at the library labels Oct 27, 2020
@garydevenay garydevenay linked a pull request Oct 27, 2020 that will close this issue
Open
8 tasks
@garydevenay
Copy link
Author

@eshanholtz Created a PR for the above solution.

@garydevenay
Copy link
Author

Update on the above:
The solution above (including my amendments) still doesn't actually work with attachments. All attachments that come through inbound parse are corrupt.

I can't make any more progress on this as I'm unable to test Inbound Parse's requests on a non-production environment and the provided unit tests aren't a reflection of Inbound Parse's POST request.

This either needs to be looked at by a core member or Twilio/Sendgrid need to supply us with a valid method of testing this locally, but the service does not work as it stands.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
status: help wanted requesting help from the community type: community enhancement feature request not on Twilio's roadmap
Projects
None yet
Milestone
No milestone
2 participants
@garydevenay @eshanholtz