HAR Schema Questions & Discussion about httpsnippet HOT 8 CLOSED

What handles schema errors?

1. har-validator is used to validate the HAR input based on HAR 1.2 Spec
2. in src/index.js I specifically add any missing input properties before validation, to make it simpler and faster to create input json files (rather than having to add in an empty cookies: [] array, and specificy httpVersion every time for example)

It seems weird having to make checks such as:

if (this.source.postData && (this.source.postData.params || this.source.postData.text)) {

yes, it is, and you shouldn't be doing that, at least, it seems you're approaching the issue thinking only of Unirest. there are libraries that allow you to set a raw body AND set parameterized POST data at the same time ... I see no reason for httpsnippet to limit that behavior ... it should be left to the discretion of the implementer to use what makes sense for the library.

keeping the implementation simple, it would be enough to check that .text and .params are mutually exclusive:

if (this.source.postData.text) {
  // request body
}

if (!this.source.postData.text && this.source.postData.params) {
  // construct post params
}

Cannot build a native JSON object when mimeType is 'application/json'

other than JavaScript, I'm not aware of any language that has native JSON support, so therefore if you want to implement whatever native equivalent of JSON, you probably have to parse it first with JSON.prase, then process / convert it to that native as well ... I don't see any way around that?

No way to know the response type in advance?

I'm going to be soon adding the ability to reference a FULL HAR object / file rather than just the request portion of it, which should give the ability to review the response object and construct accordingly.

from httpsnippet.

yes, it is, and you shouldn't be doing that

No, I have no other choice. It makes me do even uglier things for Unirest. I need a way to know wheter or not a request as a body. And it seems that the existence of postData actually doesn't mean anything.

I'm not aware of any language that has native JSON support

I should have put native in quotes but you got the idea.

so therefore if you want to implement whatever native equivalent of JSON,

I know I could parse it, I'm just saying now I have to do it for every language because your schema doesn't already do it...

Basically I know your points. I am just trying to start a discussion about whether or not HAR is the right schema to handle snippets creation honestly... I find the Mashape one way more appropriate.

from httpsnippet.

har-validator is used to validate the HAR input based on HAR 1.2 Spec

I know that. Same thing, I'm just saying we should add a layer of error handling. When the HAR format is valid but the informations are not enough to properly build a request snippet. (see the postData example, and #8)

from httpsnippet.

And it seems that the existence of postData actually doesn't mean anything.

yes, as mentioned, postData is always generated regardless of source, I still think you're not looking closer at the HAR spec, here's another valid way of doing body work:

if (this.source.postData.text) {
  // request body
} else {
  if (this.source.postData.params) {
    // construct post params
  }
}

basically the existence of postData.text overrides everything (and is the easiest, just sent content-type header and send the string of text)

also, postData.params are not JUST the key/value pair for application/x-www-form-urlencoded ... in the case of multipart/form-data you have to traverse each param, and parse it's value individually as some would be a file, others can be any content (text, video, etc ...)

ex:

"params": [
    {
        "name": "file",
        "value": "[content of the pdf file]",
        "fileName": "example.pdf",
        "contentType": "application/pdf",
    }
]

in this case you should parse the fileName field and use that in the code (to look up and read content of the file) then pass that content as the multipart/form-data request with the specified name.

I know I could parse it, I'm just saying now I have to do it for every language because your schema doesn't already do it...

I could pre-parse the JSON object into a property called this.source.json or something ... but then I would also have to traverse all the potential multipart/form-data params and look for any existence of application/json (or any of the 5 other headers representing JSON) and parse those as well ... its doable... but seems like a lot ... any better suggestions?

I find the Mashape one way more appropriate.

the Mashape schema is lacking in many places, it only covers the most popular use-cases and certainly does not deal with multipart/form-data at all!

from httpsnippet.

this is a good discussion regardless, perhaps if any valuable lessons come out of this, we can share with the HAR community :)

from httpsnippet.

(Your code snippet for body work still does not do the job if one wants a definitive way of knowing whether or not a request has a body. Doing it like that, I would have to duplicate my code. The if statement mentioned in the first comment is still the only way of knowing whether or not the request has a body.)

True for the multipart requests, however I still believe the Mashape snippets are simpler (and they are actually way shorter (thanks also to the helpers)) but also because the schema is simply less flexible.

from httpsnippet.

with recent guideline added and utility properties, this solves 90% if not all the of concerns discussed here...

from httpsnippet.

I approve this message.

from httpsnippet.