Cors Issue during XMLHttpRequests

Hi there, we've noticed an increase of 404s on published documents.

We get a CORS issue with XMLHttpRequest to the API URL from the regular site domain.

It doesn't happen all the time, but some docs that have not been re-published in a while.

Can Prismic make sure CORS access exists? What's the best best way to get you repo specifics?

Hello Ryan,

CORS issues are extensive and happen for a various number of reasons. We can try and debug this together; I'll need a little bit more context:

  • Which repo specific details are you referring to?
  • Can you give me more information about what technology your website is built in and how you're making your request?

Thanks.

is there a way for prismic to set the CORS to allow XMLHttpRequest from the domain so this is not a problem?

Hey Ryan, thank you for sending over the details. I'll share this with the team and I'll come back when I have more information.

Thanks

1 Like

Hi Ryan,

So we finally got some feedback from the team. Sorry about the delay on this. The issue is that your GraphQuery request in the URL is far too large. The URL request is limited to 2048 characters, whereas your URL is 3659 characters long.

There are certain things you can do to reduce the size of the URL. For example, GraphQuery provides you with the Fragment Syntax which allows you to retrieve all fields in a document using three dots ..., you can read about that here:

You can also try reducing whitespace in the URL which creates a lot of characters in the URL when encoding.

Hopefully, this helps.

Thanks.

Thanks, Phil,

Will ...postFields grab all slice content that is entered?

eg:

const postGraphQuery = { post { ...postFields authors { author { ...on author { full_name role bio avatar } } } categories { category { ...on category { title description image } } } related_posts { post { ...on post { title meta_decription share_image } } } } }

How can we strip more white space without breaking the structure of the query?

what are other ways we need to trim down the query to still the data represented here?

do we just do for example

related_posts {
post {
...on post {
...postFields

}
}
}

also, is there a way to condese the white space to related_posts { post { ...on post { ...postFields }}} instead of needing the white space and line breaks?

Thanks

For Slices you grab all the info like:

{
  blog {
    body {
      ...on text_block {
        non-repeat {
          ...non-repeatFields
        }
      }
      ...on image_gallery {
        non-repeat {
          ...non-repeatFields
        }
        repeat {
          ...repeatFields
        }
      }
    }
  }
}

We explain that in more detail here:

For removing the whitespace you'll still need the new lines, so it will work like your example here:

{
blog{
body{
...ontext_block{
non-repeat{
...non-repeatFields
}
}
...onimage_gallery{
non-repeat{
...non-repeatFields
}
repeat{
...repeatFields
}
}
}
}
}

You can use this tool to do it for you:

thanks well give that a try

1 Like

removing the whitespace DRAMATICALLY dropped the query stream down to 600. Honestly, we thought it needed the tabs and spaces to no break the query.

Here is some text you could add to the docs

(Attachment Untitled document.edited.docx is missing)

I'm really glad this worked for you, I'll definitely update the docs. Can you copy and paste the text you wanted to suggest here, because the attachments aren't working?

Thanks.

Sure :slight_smile:

Optimization Tips
Our graphQuery object is a powerful tool when using GraphQL is not an option or when you need to make fewer queries on related documents, but it has limitations.

The total api request, with query params, needs to be less than 2048 characters (including escaped characters like "{").

The above graphQuery examples show the object structures, but you can reduce your string length by using linebreaks with no spaces or tabs like:

{
blog{
title
main_image
description
author_link{
...on author{
...author_Fields
}
}
}
}

You can use a white space removal tool, or trim the spaces with your chosen programing language.

1 Like

Thanks Ryan,

We've updated this with the extra information now.

:slight_smile:

Nice job! I think that will help people. I didn't know just line breaks were an option. trimming just those saved a lot of characters.

1 Like

I totally agree, I'll look in to make a full document about optimisation in the future.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.