We are using a akeneo/pim-community-dev installation in version 1.6.23. We are hosting this instance on platform.sh. Since platform has updated their WAF, we now can't update large datasets because the ajax request is invalid. The support of platform told us, that the request being made by akeneo PIM is not RFC compliant. The maximum amount of keys in a form-urlencoded send is 4000 according to the RFC. Since they did not specify a key, every character gets recognized as a key. And thus it fails.
The solution would be sending the data differently. Instead of doing --data '{"code":"vgrp_dur..... we should do --data 'jsondata={"code":"vgrp_dur.....
I actually don't know where I could change the code to do this ... Has someone the knowledge or can give me a hint?
I've found the related part of code and made a composer patch to fix it for the version ^1.6: https://gist.github.com/PaperCoder/63a62d029f7cd879b3ce1b6ac0470e0c
I added the correct contentType to the $.ajax-JQuery-Call.
Related
As we all know, in the change from v11 to v12, cache was introduced, however I can't find anything online that explains exactly what it is as a concept. Can anyone explain how it works?
I have just taken a look at the D.JS source and thankfully it is heavily commented.
In many files it suggests that any message that is sent by a user, or any message mentioning a user caches said user. This works in the same way with guilds I believe.
This means that in order to find a user in a server using #get or other fetch methods, the user must have been mentioned, or typed a message.
BaseManager.js source file here
Client.js source file here
GuildManager.js sournce file here
I am running Solr 4.1, and I need to change my schema. I modified the schema file, but it doesn't seem to pick up the changed schema. I even rebooted my server.
Also, how do I see my schem? I tried to do curl http://localhost:1080/Mark/names/schema?wt=json and I get
The origin server did not find a current representation
for the target resource or is not willing to disclose that one exists.
I can curl the same endpoint and get a document just fine.
How do I get Solr to pick up the new schema?
I had an error in my code that was indexing the data. I was setting the values for the new fields, but I did not realize that there was another method buried deep in the bowels :) that stripped it off.
Turns out, Solr picked up the changes, I just didn't send the data for it.
I've faced ResponseTooLargeError when using AppEngine's urlfetch.fetch because my response was several Mb big. (doc)
I see there is a allow_truncate param I can pass and it will truncate the response if too big. Is there any way then to request the rest of the response ? Something like making new calls to the same URL with an offset ?
Otherwise I don't really understand how this param can be useful (just checking if it returns without error ?)
Thanks
There is no standard way of requesting the "rest of the response", it all depends on the particular server-side implementation of the service you're working with: if it offers support for transferring data in smaller chunks, and, if it does, how exactly that works, i.e. the exact protocol for performing such transfers. Some may even consider such capability a part of the service itself.
Just to get an idea of what the implementation might look like you can see some possible options for a particular service discussed in Very large HTTP request vs many small requests
Yes, the usefulness of the option is to be able to get a partial response vs just getting a ResponseTooLargeError (which might be sufficient in some cases).
The documentation of JSON-LD mentions that clients can provide a profile parameter to the Accept header can be used to control the representation. It defines the three defaults for requesting compacted, expanded or flattened JSON-LD documents. It does also say that
If the profile parameter is given, a server should return a document that honors the profiles in the list which are recognized by the server.
It does not, however, explain whether there are any specific rules the server should follow. Is it completely up to the server to decide what the behavior is for custom profile URIs? Are there any discussions on that subject?
Would the examples below be correct?
Example 1
The client requests with
Accept: application/ld+json;
profile="http://www.w3.org/ns/json-ld#compacted http://schema.org"
And the server returns compacted document with http://schema.org as #context?
Example 2
The client requests with
Accept: application/ld+json; profile="http://schema.org"
And the server returns compacted document with http://schema.org as #context?
The JSON-LD 1.0 Spec defines profile in IANA Condierations. This defines the profile identifiers such as compacted you identified above. It doesn't provide a way to specify a specific context to use, and the semantics of profile would make it difficult to know what is meant by a different profile URI, as there is no way (AFAIK) to register this meaning elsewhere.
That said, I think it would be useful to be able to specify a context to use for compacted or expanded, and if/when we support framing, a frame to use. I think this might take the form of a type-specific Accept parameter context and/or frame, which would be used to specify the requested context or frame to be used when serializing the document. However, as with other profiles, these are SHOULD, not MUST; a client needs to be able to cope with getting a document back not so serialized, perhaps using a local jsonld.js instance to re-encoding the returned document. It might also be useful to recommend that the same parameters be used in the response with Content-Type for the server to communicate the profile/context/frame used as part of the response.
Please consider raising an issue at https://github.com/json-ld/json-ld.org/issues, as we're starting to look at new Community Group (i.e., not W3C Recommendations) drafts of the specs to address long outstanding community feature requests.
How would one create a REST web service to write a row into a databse table. Use the follwoing scenario:
The table is called Customer - the
data to be inserted into the row would
be the name, addresss, telephone
number, email.
I think its impossible to describe the whole thing end to end in Java or C#, and I would never expect that, but here are the questions I have popping into my head as I prepare for coding:
How the URI would look (eg. if you use this URL - http://www.example.com/)?
What info would go into the HTTP envelope?
Would I use POST when writing to the database in this way?
Do I use a resource to store the posted data from the client? Is this even necessary if the data is being written to a database anyway?
When the data to be writeen into the db is recieved by the server - how do I physically insert it into the database - do I call some method on the server to actually write the data (in Java)? - this doesn't seem to fit with truely REST architecture - shunning RPC calls.
Should I even be bothering writing to a DB - should I be storing my data as a resource?
As you can see I need a few issues clearing in my head. Any help much appreciated.
First of all, I'm not either java nor c# expert and I don't exactly know what means do these languages have to support REST design, but in general:
http://www.example.com/customers - customers is a collection of resources and you want to add a new resource to this collection
It depends on various things - you should probably set the content-type header (according to the data format in which you are sending the representation) and set some authentication headers if you need it.
Yes, you always use POST to create a new entry in a collection of resources.
I don't fully understand this question, to be honest. What do you mean by "inmediately writing data into the database"?
REST is primarily just a style of communication between server and a client. It doesn't say anything about how you should handle the data received by using it. The usual way how modern web approaches (MVC style frameworks) solve it, is by routing every REST action to a method of some class (usually a controller instance) where you handle the received parameters (eg. save them to the database) and generate a response to be sent back.
For a very brief and very clear introduction to REST have a look at this short video.
RESTful Web Services, published by O'Reilly and Associates, seems to fit the bill you're looking for.
As far as doing it in Java, Sun has a page on it.